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