BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

TDD会破坏架构吗?

| 作者 Andrew Morgan 关注 3 他的粉丝 ,译者 汪佳南 关注 0 他的粉丝 发布于 2017年4月6日. 估计阅读时间: 3 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

作为敏捷宣言的共同作者,我们熟知的鲍勃大叔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只是一条守则,是组织工作的方法,是确保测试覆盖率的途径,是在应对特殊性的同时确保适当通用性的手段。

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

查看英文原文Does TDD Harm Architecture?


感谢冬雨对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT