前言

韩陈昊

对于测试驱动开发，很多人会无法理解为什么要用这样的方式来开发：为什么要让开发人员写测试？开发写了测试，QA就不用再测了吗？又写测试又写业务代码效率是不是很低？不写测试我一样可以写出可工作的软件，那写测试会有什么额外的好处？

从直觉上看，测试驱动开发相当令人疑惑，因为它主张通过构造一系列自动化测试，为编写代码做指引，甚至提倡先测试失败，再写对应业务代码。在国内较为普遍的软件开发模式中，程序员经常利用控制台或者postman的输出结果，来判断自己完成的功能正确与否。这其实就是一种无计划的手动验证性测试，这个过程有测试的行为，有预期明确的执行结果，也有针对结果的验证，很容易转化成自动化来完成。

还有一种比较常见的场景是定位性测试，在遇到某些问题，我们debug的时候需要断点调试，这种调试更像是一个探索的过程，我们根据出现的错误寻找可能出现错误的位置，然后设计断点，判断断点处的状态是否正确。

其实构造软件的过程，就是通过一系列的验证测试，证明我们朝着正确的方向前进，如果验证出现了错误，那么再通过一系列的定位测试找到问题原因，然后加以改进，如此以往直到完成全部功能。所以从某种角度上看，测试构成了整个开发流程的骨架，功能开发可以看作填充在测试与测试之间的血肉。

所以测试驱动开发的核心逻辑是：以测试作为切入点，帮助我们掌控整个研发过程。一个个测试就像很多里程碑点，规划着研发活动的进度，围绕着这些里程碑，就可以对成本和效率进行持续管理和改进。在这个过程中，无计划的手动验证和手动定位验证将会被认定为成本很高的工作手段，所以有计划的自动化验证和逐模块的自动化排查成为了研发工程化的最佳实践。测试驱动开发的最直接的收益，就是可以提高研发的工程效能，它不仅仅是指开发功能的效率，还包含发现问题、定位问题以及修复问题的效率。

我们的生产效率之所以变得越来越慢，之所以出现不敢改祖传代码的情况，就是因为大多数情况下所做的修改一旦出错，就很难定位到是因为什么出的错，而TDD既是我们实现软件过程中的记录，同时也可以很容易帮助我们定位软件中存在的问题，以及定位问题产生的原因。

在思考职业发展时，我常常会把目光聚焦在技术上，比如chatGPT现在火了，我要追吗？某个框架出新版本了，国内还没有普及，我要去看看吗？在思考这个问题的时候，我想起了熊节常说的软件工程能力，从根本上讲，我们现在不光要注重自己的技术能力，还要更多的重视工程能力，希望通过这次对TDD的学习，对工程实践有一个新的理解。