我应该更改代码以使其更易于测试吗？

Question

我经常发现自己更改了代码以使其更易于测试，我总是想知道这是不是一个好主意。我发现自己做的一些事情是：

1. 添加setter，这样我就可以将内部对象设置为mock。
2. 为内部地图/列表添加getter，以便在执行某些外部操作后检查对象的内部状态是否已更改。
3. 包装具体系统类并创建一个新界面，以便我可以模拟它们。例如，File类很难模拟 - 所以我将创建一个新的接口FileInterface和WrappedFile，它扩展它，然后使用FileInterface而不是File。

Answer 1

更改代码以使其更易于测试可能是一件好事，但前提是它使代码本身更好。重构可测试性可以使您的代码更好地独立于测试套件的需求。这些都是很好的改变。

在你的三个例子中，只有＃3是一个非常好的例子;通常，这些新接口将使您的代码更灵活，以便以后经常使用。 ＃1通常用于通过依赖注入进行测试，在我看来，这会使代码变得更加复杂，但至少会使测试变得更容易。 ＃2听起来总体上是一个坏主意。

Answer 2

完全没问题，甚至建议更改代码以使其更易于测试。以下是10 things that make code hard to test。

的列表

我认为你的第三个确实没问题，但我不太喜欢第一个和第二个。如果你只是用getter和setter打开你的类内部，那么你就完全放弃了封装。根据您的语言，有一些方法可以打开一些参数进行测试。但是我实际做的事情（打开封装的次数少一点）就是让我想检查的字段受到保护（当依赖注入无法解决问题时）。

然后，在测试项目中，我继承了类，并创建了一个“更强大的”，我可以检查内部，但是我没有对实现进行任何更改，并在测试中使用此类。

最后，强烈建议更改代码以实现依赖注入和控制反转，因为它使您的代码更易于测试，更易读和可维护。

虽然改变是好的，但最好的办法是TDD。一旦首先编写测试，它就会自然地生成可测试的代码。

Answer 3

这是一种权衡......

你想要一个纤薄，流线型的API或一个更臃肿的更复杂，但更容易测试的。

不是你想听到的答案，我知道：）

Answer 4

似乎合理。有些事情不需要检查;我建议检查是否添加到列表是否有点无用。但做任何你觉得舒服的事情。

Answer 5

理想情况下，您设计的每个类都应该自行测试，因此您无需更改公共接口。但是你在谈论遗留代码，所以我认为只有当公众影响不明显时，改变代码才是合理的。我宁愿添加一个静态内部类来测试而不是测试类的接口膨胀。