我一直在阅读单元测试，TDD和SOLID原则，我需要一些澄清。我的理解是，如果一个人坚持开放/封闭原则，单元测试可能在很大程度上变得不必要，因为代码不能修改 - 因此如果代码被正确隔离和解耦，则无需重新测试。如果一旦代码通过相关的单元测试就不会改变单元测试所增加的前期成本的长期好处。代码将永远通过，因为它永远不会改变，对吧？需要测试继承的类，但是一旦它们通过相关的测试，它们也将被关闭以进行修改，并且不需要重新测试。 The Wikipedia article on OCP强化了第一段中的这一思路，（我意识到这并不能成为法律）
我发现OCP和TDD生活在和谐中的最佳解释is here，尽管似乎Arnon说OCP赞美TDD，因为开发人员不鼓励修改源代码，因为现有的测试方法在修改后会变得复杂测试新功能。
这就是它的全部吗？请注意，我不是在寻找一个论点，我是新手，我正在寻找那些对这个主题有更多经验的人的澄清。
答案 0 :(得分：8)
即使你接受一旦软件工作并且没有改变，你不需要测试它（我没有），你仍然需要显示组件在第一个工作放置。我认为最好的方法之一是单元测试。
另外，实际上，一旦进行了测试，运行它的成本非常低。因此，即使组件没有发生变化，通过不断运行测试也不会失去太多。此外，有时设计更改，你需要返回并重做一些组件 - 在这种情况下单元测试肯定有帮助......
请记住，拥有测试套件的一个结果是它通过显示某些内容发生变化来提升可维护性。因此，即使您的团队在SOLID中关注O，这并不意味着事情不会意外地改变。因此，测试通过显示某些内容是否会被无意中更改来帮助实现，并且它们会向您显示受更改影响的确切内容。
答案 1 :(得分：4)
由于代码无法修改，因此单元测试可能变得非常不必要
嗯，一点也不。你怎么知道原始的，封闭的，实现是否正确？
单位测试增加的前期成本的长期利益已经丧失
软件工程经济学的一个重要发现是，在产品生命周期的后期检测和修复缺陷的成本要高得多。 IIRC，在经典的“瀑布式”开发过程中，每个阶段大约一个数量级。由于单元测试（无论是TDD还是测试优先）可以及早发现缺陷，因此可以快速收回成本。
它不会改变
如果它有缺陷，则必须更改。当然，如果您可以保证您的代码没有缺陷，那么您说的是真的。但是，如果您可以保证您不需要任何类型的测试。但很少有软件项目能够提出这样的要求。