我已经阅读here，在大多数情况下，首选黑盒测试（仅测试没有实现细节的API）。但是，如果我只编写黑盒测试，我不关心实际的实现，从哪里知道如何处理方法的任何依赖性来测试？想象一下，我们在我们的方法中进行数据库调用以进行测试。通常我会以一种总是返回一些假数据的方式伪造该调用，以便测试我自己的方法是否相应地处理该数据。在我的测试中，我不关心数据实际来自哪里，所以我假装它。
在一个黑盒子上，我不知道该弄什么以及怎么做，而在一个白盒子上，我知道内部的东西和那些叫做假的。
所以我的问题是：依赖处理是否与黑盒测试有关？
答案 0 :(得分：1)
我认为您误解了链接文章的意图。建议是关注行为而不是实现，因为这意味着您的测试将不那么脆弱，并且如果实现更改则不需要更改。不要混淆你的内部实现和你的依赖。如果你的类有依赖关系，那么可以提供这些的模拟（除非你的测试是集成测试或依赖是实现细节）。实现的更改与依赖项的更改之间存在差异。
在你的例子中，如果你正在调用数据库来获取一些数据而你想要模拟它，那么这很好，你的设置需要考虑到这一点，但要关注测试中的预期输入和输出，不要和＃39;尝试检查类的内部，或与辅助类的交互，这是一个实现细节。
在链接到AdderFactory更改的示例中，实现细节更改而不是依赖项更改，因为此处不需要模拟任何内容，现有测试也将继续测试AdderFactory。
如果您可以更改课程的实施而且您不需要更改测试，那么您就是正确的，如果您需要更改每个测试，因为您更改了课程的内部（而不是这个类的依赖关系，然后这是一种气味，你应该再看看你的测试。