测试驱动开发和开放/封闭原理如何协同工作？

Question

我一直在阅读单元测试,TDD和SOLID原理,我需要一些澄清.我的理解是,如果遵循开放/封闭原则,单元测试可能在很大程度上变得不必要,因为代码无法修改 - 因此,如果代码被正确隔离和解耦,则无需重新测试.如果一旦代码通过相关的单元测试就不会改变单元测试所增加的前期成本的长期好处.代码将永远通过,因为它永远不会改变,对吧？需要测试继承的类,但是一旦它们通过相关的测试,它们也将被关闭以进行修改,并且不需要重新测试.关于OCP的维基百科文章强化了第一段中的这一思路(我意识到这并不能成为法律).
我发现在OCP和谐和TDD生活最好的解释是在这里,但它似乎是嫩说,OCP恭维TDD中,开发商从修改源代码的沮丧,因为修改,以测试新的时,现有的测试方法会变得复杂功能.
这就是它的全部吗？请注意,我不是在寻找一个论点,我是新手,我正在寻找那些对这个主题有更多经验的人的澄清.

Answer 1

即使你接受一旦软件工作并且没有改变,你就不需要测试它(我没有),你仍然需要显示一个组件首先工作.我认为最好的方法之一是单元测试.

而且,实际上,一旦你进行了测试,运行它的成本非常低.因此,即使组件没有发生变化,通过不断运行测试也不会失去太多.此外,有时设计更改,你需要返回并重做一些组件 - 在这种情况下,单元测试肯定有帮助...

请记住,拥有测试套件的一个结果是它通过显示某些内容发生变化来提升可维护性.因此,即使您的团队在SOLID中关注O,这并不意味着事情不会意外地改变.因此,测试通过显示某些内容是否会被无意中更改来帮助实现,并且它们会向您显示受更改影响的确切内容.