首发于极光日报
TDD 伤害了软件架构吗?

TDD 伤害了软件架构吗?

简评:个人认同 Uncle Bob 能损害软件架构的只能是开发者的说法,但也认为对于绝大多数开发者而言,更多的测试其实意味着更多的 bug。

TDD (Test-driven development) 即测试驱动开发,要求开发者在编写某个功能的代码之前先编写测试代码,然后只编写使测试通过的功能代码,通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码,并加速开发过程。

但对于 TDD 的争论一直没有停止,而最近在 twitter 上关于 TDD 是否有损软件架构的争论再起。这里著名的 Robert C. Martin (Uncle Bob Martin) 写了一篇博文发表自己的观点,也推荐大家看看 Rails 之父 DHH 相反观点的一篇文章,然后自己加以判断。

对于 TDD 一个常见的观点就是「当你有了越来越多的测试时,也就意味着越来越难以改动业务代码。因为改动会造成很多的测试失败而需要修正,所以测试会让业务代码变得死板,难以改动」。

对此 Uncle Bob 展示了一幅图:

对于哪一边更好相信不用多说,右边的设计明显更加合理。

右半边的图用到了经典的 OCP (Open-Closed Principle) 和 DIP (Dependency Inversion Principle) 原则。与用户直接联系的是 API,而服务端负责实现 API,因此用户基本不会直接察觉到服务端的变动。

文中,Uncle Bob 提示大家将上图中的 USER 替换成 TEST 再思考。测试和业务代码一样也需要好好设计,而大多数人只是简单的写出一一对应的测试代码,那当然会难以改动,产生各种各样的问题。Uncle Bob 认为设计模式等改善代码结构的原则同样可以用于测试代码中,并且应该将测试代码和业务代码放在同样重要的地位。

就结论来说,Uncle Bob 认为 TDD 本身并不会伤害软件架构,是开发者不会用。也就是如果你不能好好组织设计你的测试代码,意味着你写的业务代码也好不到哪儿去。是你自己而不是 TDD 损害了你的软件结构。

原文:TDD Harms Architecture

扩展阅读:


欢迎关注知乎专栏「极光日报」,每天为 Makers 导读三篇优质英文文章。

编辑于 2017-03-06

文章被以下专栏收录