13 | 先写测试，就是测试驱动开发吗？
郑晔
该思维导图由 AI 生成，仅供参考
你好，我是郑晔。
在上一讲中，我向你说明了为什么程序员应该写测试，今天我准备与你讨论一下程序员应该在什么阶段写测试。
或许你会说，写测试不就是先写代码，然后写测试吗？没错，这是一个符合直觉的答案。但是，这个行业里确实有人探索了一些不同的做法。接下来，我们就将进入不那么直觉的部分。
既然自动化测试是程序员应该做的事，那是不是可以做得更极致一些，在写代码之前就把测试先写好呢？
有人确实这么做了，于是，形成了一种先写测试，后写代码的实践，这个实践的名字是什么呢？它就是测试先行开发（Test First Development）。
我知道，当我问出这个问题的时候，一个名字已经在很多人的脑海里呼之欲出了，那就是测试驱动开发（Test Driven Development），也就是大名鼎鼎的 TDD，TDD 正是我们今天内容的重点。
在很多人看来，TDD 就是先写测试后写代码。在此我必须澄清一下，这个理解是错的。先写测试，后写代码的实践指的是测试先行开发，而非测试驱动开发。
下一个问题随之而来，测试驱动开发到底是什么呢？测试驱动开发和测试先行开发只差了一个词：驱动。只有理解了什么是驱动，才能理解了测试驱动开发。要理解驱动，先来看看这两种做法的差异。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
测试驱动开发（TDD）是程序员们讨论已久的话题。与测试先行开发不同，TDD强调“红-绿-重构”的节奏，即先编写测试（红），然后编写功能代码使测试通过（绿），最后进行重构。TDD的核心在于驱动代码质量的提升，而不仅仅是先写测试后写代码。文章还探讨了编写可测试代码的重要性，以及如何调整设计以实现可测性。此外，文章还提到了测试驱动设计（Test Driven Design）的概念，强调了测试驱动开发对代码设计的影响。总的来说，TDD已成为行业中的优秀实践，学习TDD的第一步是记住“红-绿-重构”的节奏，并且应该编写可测的代码。文章鼓励读者分享对TDD的理解，并欢迎留言讨论。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《10x 程序员工作法》，新⼈⾸单¥68
《10x 程序员工作法》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(39)
- 最新
- 精选
邵俊达最近在一个新项目中尝试使用了 TDD 有测试保驾护航是真的爽。事情是这样的，今天经过讨论要把一个模型替换掉，刚听到这个消息的时候我是崩溃的，心想这要是出 bug 怎么办，到转念一想我测试覆盖率 88% 应该还好，动手改完跑起测试，果然不过，但是只是几个叫小问题，再次运行测试 绿灯！我的天，此时内心别提多么舒爽，这要是没有测试我今晚应该不用睡了，谢谢老师。最近也开始先分解任务再小步提交，这么做下来有一种很踏实的感觉，同事 review 代码也舒服很多。作者回复: 恭喜你，进步了！
2019-04-17348
行与修测试驱动不但可以写出精炼的代码，还能养成良好的编程习惯和设计思维， 相辅相成。 团队达到这种状态还真是不易，架子搭好了有人觉得没发挥空间，要是放开了代码又会五花八门难以测试。莫名有种担心，会不会为了测试而测试在代码里混搭着workaround 呢?作者回复: 测试应该是什么样子，后面即将呈现，敬请期待！
2019-01-3014
彩色的沙漠阅读之后有了基本的认知，还需要阅读这方面的相关书籍和实践作者回复: 更重要的是练习
2019-01-3010
Sudouble之前在其他领域的里也有介绍负反馈相关单位内容，各个领域之间还是有很多互通之处。软件或者其他系统一直处于熵增的状态，需要持续的保养和维护。不得不感慨大道至简啊作者回复: 一通百通
2019-02-119
sam学完这篇，真正了解了TDD，以前一直凭直觉理解TDD是完善测试驱动开发，现在发现最根本是驱动代码设计。作者回复: 这回理解是对的。
2020-07-047
西西弗与卡夫卡印象最深的几次TDD。 1. 是个CS应用，从服务端拉取数据后，根据不同状态，客户端执行不同逻辑。采用的方法是，将服务端的响应值记录，然后在测试代码里回放，不依赖服务端。修bug时，每个bug就是一个测试，测试代码里直接回放记录的服务端响应。好处是，回归非常快，而且不依赖服务端 2. 上家公司要做HA软件开发，情况很复杂，手工做测试代价很高。正好赶上docker兴起，于是就写了很多“暴力”代码（比如直接kill服务、删除服务等）测试各种场景，只留少数必须用物理机测试的场景交给人工作者回复: 第一个像验收测试，第二个像暴力测试。
2019-01-287
红糖白糖TDD，和任务分解可以说是相辅相成。 在写测试的时候，一个一个的case其实在对任务的分解，考虑每个case所要达到的目标，输入、输出，以及case与case之间的衔接。写测试的时候，我们是站在一个consumer的角度来的，考虑的是这个case的输入和输出。首先，这对于设计能力有一定的要求，其次，按照这种方式写出来的代码可用性更高。因为我们的起点是consumer 而不是provider作者回复: 关于设计，欢迎加入《软件设计之美》。
2019-03-1025
又双叒叕是一年啊好感动哭了编辑回复: 这位同学，你是认真的吗😁
2019-01-284
escray
之前在学习 TDD 的时候，确实忽略了“驱动”的概念，而且也有很多时候，根本驱动不起来。 从测试先行开发，通过重构，成为测试驱动开发，进而成为测试驱动设计。 以前似乎也忽略了重构，只注意“红-绿”的节奏，而把重构当做了测试驱动开发之外的一个动作，其实重构，或者说是小规模的重构，应该是 TDD 的应有之意。 这个任务分解的模块，其实更多的讲的是 TDD，准备把《测试驱动开发》也一并读一下。作者回复: 《测试驱动开发》值得细细品味。
2020-06-093
liu以前以为测试驱动开发只是先写测试，再开发就完了。原来还有重构。想想也对。代码第一步完成功能表达，但未经重构的代码必然存在坏味道。重构，才能使代码机构清晰，便于理解阅读作者回复: 重构拯救代码！
2019-01-2823
收起评论
