我一直在阅读单元测试、TDD 和 SOLID 原则，我需要一些说明。我的理解是，如果遵循开放/封闭原则，由于代码对修改是封闭的，因此单元测试可能在很大程度上变得不必要——因此，如果代码被正确隔离和解耦，则无需重新测试。如果代码一旦通过相关的单元测试就不会改变，那么单元测试增加的前期成本所带来的长期 yield 就会丧失。代码将永远通过，因为它永远不会改变，对吧？继承的类需要进行测试，但一旦通过相关测试，它们也将关闭修改，不需要重新测试。 The Wikipedia article on OCP加强了第一段中的这一思路，(我意识到这并不合法)。
我找到的关于 OCP 和 TDD 和谐相处的最佳解释 is here ，尽管 Arnon 似乎是在说 OCP 是对 TDD 的补充，因为不鼓励开发人员修改源代码，因为在修改现有测试方法以测试新功能时可能会变得复杂。
这就是全部吗？请注意，我不是在寻找争论，我对此很陌生，我正在寻找比我更有经验的人的澄清。
最佳答案
即使您接受了，一旦软件可以工作并且不会改变，您就不需要对其进行测试(我不需要)，您仍然需要首先证明组件可以工作。我认为最好的方法之一是单元测试。
此外，实际上，一旦您进行了测试，运行它的成本就非常低。因此，即使组件没有改变，持续运行测试也不会损失太多。此外，有时设计更改，您需要返回并重做一些组件 - 在这种情况下进行单元测试肯定会有所帮助......
请记住，拥有测试套件的一个结果是，它可以通过显示某些更改的时间来提高可维护性。因此，即使您的团队遵循 SOLID 中的 O，也并不意味着事情不会被意外更改。因此，测试通过显示是否无意中更改了某些内容来提供帮助，并且它们会准确地向您显示受更改影响的内容。
关于unit-testing - 测试驱动开发和开放/封闭原则如何协同工作？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7904042/