你有没有遇到过这种情况：辛辛苦苦写完一段代码，刚想喘口气，结果一运行就报错。改完一个 bug，又冒出三个新的问题，像打地鼠一样忙个不停。其实，换个写代码的顺序，这些问题可以提前避免——这就是测试驱动开发（TDD）的魅力。
先写测试，再写实现
TDD 的核心流程被称为“红-绿-重构”。听起来像交通灯，其实也差不多是给编程过程亮起了信号灯。
第一步是“红”：先写一个测试用例，但这时候还没有实际功能代码，所以测试肯定会失败。这个失败的状态就是“红灯”，提醒你功能还没实现。
比如你要写一个计算两个数相加的函数，别急着动手实现，先写个测试：
def test_add():
assert add(2, 3) == 5此时如果你还没定义 add 函数，运行测试就会报错，红灯亮起。
让灯变绿：写出最简单的通过代码
接下来是“绿”：写最少的代码，让测试通过。哪怕写法看起来有点傻也没关系，目标是让测试从红色变成绿色。
比如你可以这样实现：
def add(a, b):
return 5没错，这显然不对，但它能让当前测试通过。虽然可笑，但这正是 TDD 的起点——先让系统“动起来”，再逐步完善。
然后你再加一个测试用例：
def test_add():
assert add(2, 3) == 5
assert add(1, 1) == 2这时上面那个“永远返回 5”的函数就不行了，测试再次变红。你不得不认真实现逻辑：
def add(a, b):
return a + b测试通过，绿灯亮起。
第三步：重构，让代码更干净
现在功能正确，测试也通过了，但代码可能还不够优雅。也许是重复了逻辑，也许是命名不清楚。这时候就可以放心大胆地重构——因为有测试兜底，改坏了马上就能发现。
就像装修房子，测试就是你的安全网。你可以在不拆墙的前提下换电线、改布局，只要每一步测试都通过，就知道没出大问题。
很多人写代码是“先实现，后补测试”，但往往写着写着就忘了。而 TDD 把测试变成了开发的导航仪：每一步都有明确目标，写完就知道对不对。
在团队协作中尤其明显。新人接手老项目，如果有一堆测试用例，改代码时心里就有底；如果没有，每次提交都像在雷区走路。
红绿重构不是玄学，它是一种习惯。刚开始会觉得多此一举，写两行代码要配三段测试。但时间一长你会发现，省下的调试时间、避免的线上事故，远比多写的那几行测试值钱。