作为敏捷宣言的共同作者,我们熟知的 鲍勃大叔 Bob Martin,在最近发表的 一篇文章 中对TDD是否会损害架构进行了评估。文中大部分讨论围绕着遵循测试驱动方法对高层设计和实现代码的总体可维护性是否会产生消极影响。Martin认为,虽然TDD是重要的守则,但良好的设计来源于解耦、分离和隔离等原则。
Ruby on Rails的作者David Heinemeier Hansson曾发表过一篇有关 测试破坏了设计 的文章。Martin对此观点作了进一步探索。这篇文章基本上是对以下两种设计进行比较,其一是Hansson所倡导的设计,另一个则是Ruby的贡献者和布道者Jim Weirich所倡导的更易于测试的设计。Martin鼓励读者选择更适合自己的设计,并写道:
Martin还撰写了一篇 测试脆弱性 的 问题 。文章中提到对实现代码的细微改动都可能会对数以百计的相关测试用例造成影响,从而不得不把它们全部更新。
Martin在阐释他的观点时首先指出,不论是否遵循了TDD,测试代码都需要像产品代码那样精心设计:
Martin还解释道,对TDD的一个常见误区就是测试和实现是一一对应的。这可能意味着一个实现类对应一个测试类,一个实现方法对应一个测试方法。这种做法的不足之处主要在于,它将测试和实现紧紧绑在了一起,导致很难进行重构和梳理。
Martin认为高层架构和设计不会从TDD中浮现:
另一方面,Martin认为那些实现代码级别的低层设计确实来源于TDD的实践过程。换句话说,在测试代码保持不变的同时,实现代码可以进行重构和结构化,使得代码更具有可维护性。Martin认为这会导致事物向两个方向发展:“一方面测试变得越来越具体,另一方面产品代码则越来越通用。”
除了这些差别之外,Martin坚信TDD是一条守则。不管是否实践TDD,开发者本身才能决定良好的设计:
Martin的观点总结起来就是,TDD产出的设计事实上就是开发者的设计。TDD的主要优势在于测试覆盖率和应用程序的可靠性。真正良好的设计来源于解耦、分离和隔离等原则。
来源: http://www.tuicool.com/articles/jUj2iaE