tdd会破坏架构吗？-k8凯发

　　英文原文：

　　作为的共同作者，我们熟知的bob martin，在最近发表的中对 是否会损害架构进行了评估。文中大部分讨论围绕着遵循测试驱动方法对高层设计和实现代码的总体可维护性是否会产生消极影响。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 只是一条守则，是组织工作的方法，是确保测试覆盖率的途径，是在应对特殊性的同时确保适当通用性的手段。

　　martin 的观点总结起来就是，tdd 产出的设计事实上就是开发者的设计。tdd 的主要优势在于测试覆盖率和应用程序的可靠性。真正良好的设计来源于解耦、分离和隔离等原则。