为测试而设计或停止为测试而设计答案

【问题标题】：Design for test OR Stop designing for test为测试而设计或停止为测试而设计
【发布时间】：2010-09-16 05:39:23
【问题描述】：

所以哪个更好。我们是否开始让测试设计我们的代码。我们是否开始为依赖项引入构造函数注入只是为了使代码可测试？还是我们使用“覆盖”受保护的方法和被测类的子类。

【问题讨论】：

那么依赖解耦的构造函数注入呢。
阿门。每当我花时间为现有（甚至是新）代码编写自动化测试时，我都会问自己这个问题。似乎没有任何设计足以同时满足应用程序和测试。当然，解耦是好的，但测试引入了一个新的要求，需要从下到上进行巨大的改变。
这两种方法都是合理的，具体取决于上下文...

【解决方案1】：

如果您的测试设计良好，它们将模拟实际使用情况。因此，一套非常好的单元测试将涵盖应用程序可以利用您的代码 ~~will~~ 的所有可能方式，应该会产生一个健壮的实现。如果您的测试有缺陷，那么您不会获得太多收益。

【讨论】：

【解决方案2】：

我非常同意 Staale，设计良好的代码应该是可测试的。
我不使用构造函数注入或派生类进行测试。我相信使用“服务定位器”是进行依赖注入的正确方法。

【讨论】：

【解决方案3】：

我通常认为可测试的代码是好的代码。为了使代码可测试，您需要更好的解耦，以便可以使用测试工具单独测试每个组件。但是，实现中不应该有仅由单元测试使用的代码。

另外，请记住，您需要测试的是对象的公共 API，而不是受保护/私有方法。在私有/受保护方法中查找错误应该是日志记录/调试器的用途。毕竟，其中的错误也会传播到公共方法。所以只要公共方法满足测试，受保护的方法也会被覆盖。

如果您使用的是 java，并且在同一个包中具有实现公共接口的包范围类，我会将单元测试放在同一个包中的单独文件夹中以测试这些类。您还可以将单元测试与被测类放在同一个包中，以测试受保护的方法。

【讨论】：