作为敏捷宣言的共同作者，我们熟知的鲍勃大叔Bob Martin，在最近发表的一篇文章中对TDD是否会损害架构进行了评估。文中大部分讨论围绕着遵循测试驱动方法对高层设计和实现代码的总体可维护性是否会产生消极影响。Martin认为，虽然TDD是重要的守则，但良好的设计来源于解耦、分离和隔离等原则。
Ruby on Rails的作者David Heinemeier Hansson曾发表过一篇有关测试破坏了设计的文章。Martin对此观点作了进一步探索。这篇文章基本上是对以下两种设计进行比较，其一是Hansson所倡导的设计，另一个则是Ruby的贡献者和布道者Jim Weirich所倡导的更易于测试的设计。Martin鼓励读者选择更适合自己的设计，并写道：
争论的焦点在于隔离性和间接性。 DHH的优秀设计理念最小化了上述两点，而Weirichdd 设计则将这两点最大化。
Martin还撰写了一篇测试脆弱性的问题。文章中提到对实现代码的细微改动都可能会对数以百计的相关测试用例造成影响，从而不得不把它们全部更新。
Martin在阐释他的观点时首先指出，不论是否遵循了TDD，测试代码都需要像产品代码那样精心设计：
应用在测试上的设计原则应当和普通代码一样多。测试是系统的一部分，必须和系统中的其他部分那样维持相同的标准。
Martin还解释道，对TDD的一个常见误区就是测试和实现是一一对应的。这可能意味着一个实现类对应一个测试类，一个实现方法对应一个测试方法。这种做法的不足之处主要在于，它将测试和实现紧紧绑在了一起，导致很难进行重构和梳理。
Martin认为高层架构和设计不会从TDD中浮现：
坦白讲，系统的高层设计和架构会从TDD中浮现这一说法听起来很荒谬。在动手编码之前，你就应当对软件项目具备一定的架构视野。而这是TDD无法带给你的。
另一方面，Martin认为那些实现代码级别的低层设计确实来源于TDD的实践过程。换句话说，在测试代码保持不变的同时，实现代码可以进行重构和结构化，使得代码更具有可维护性。Martin认为这会导致事物向两个方向发展：“一方面测试变得越来越具体，另一方面产品代码则越来越通用。”
除了这些差别之外，Martin坚信TDD是一条守则。不管是否实践TDD，开发者本身才能决定良好的设计：
TDD不会导致坏的设计，也不会导致好的设计。开发者才是设计好坏的决定因素。TDD只是一条守则，是组织工作的方法，是确保测试覆盖率的途径，是在应对特殊性的同时确保适当通用性的手段。
本文转自d1net（转载）
