TDD 伤害了软件架构吗？

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 损害了你的软件结构。

原文转自：https://zhuanlan.zhihu.com/p/25571122