你有没有遇到过这样的情况：辛辛苦苦写完一段功能，刚想松口气，结果一运行就出bug？更糟的是，改了一个问题，又冒出三个新问题。这种情况在开发中太常见了。而“测试驱动开发”（TDD）里的“红绿重构”三步法，就是专治这种“改完更乱”的良方。
先写测试，再写代码
很多人写代码的习惯是：先实现功能，最后补测试。但TDD反其道而行之——你要做的第一件事，是写一个测试用例。这时候，代码还没写，测试当然会失败。这个“失败”的状态，就是“红色”。
比如你想写一个加法函数 add(a, b)，第一步不是去实现它，而是先写个测试：
assert add(2, 3) == 5由于函数还不存在，运行测试就会报错，测试框一片大红。别慌，这是正常的，说明测试在起作用——它已经能检测到“东西没实现”了。
让测试通过：从红变绿
接下来的目标很简单：让测试通过。不管用多粗糙的方法，先把函数写出来，哪怕硬编码都行：
def add(a, b):
return 5这时再跑测试，通过了！界面变成绿色。别笑，这一步的意义在于：你确认了测试是有效的，而且离目标只差“正确实现”这一步。
然后你再改进代码，让它真正处理各种输入：
def add(a, b):
return a + b再次运行，还是绿的。说明你改对了。
重构：趁绿赶紧整
现在测试是绿的，说明功能正常。这时候你可以放心大胆地优化代码结构，比如拆分函数、重命名变量、消除重复逻辑。每改一点，就跑一遍测试。只要还是绿的，说明没破坏功能。
比如你发现某个计算过程写了三遍，就可以抽成一个独立函数。改完一运行，测试依旧通过，心里就有底了。要是不小心改出问题，测试立刻变红，马上就能发现。
像刷牙一样养成习惯
红绿重构听起来像一套流程，其实更像一种节奏：写测试（红）→ 实现功能（绿）→ 优化代码（保持绿）。熟练之后，就像写代码时自然会缩进、加注释一样，写测试也成了下意识动作。
很多开发者一开始觉得“多此一举”，但一旦项目变大，就会发现：有测试护体的代码，改起来才不心惊胆战。尤其是团队协作时，别人改了你的代码还能保证不出问题，靠的就是这一条条绿色的测试用例。
下次写功能前，不妨试试先写一行测试。哪怕只测一个最简单的场景，也能让你的代码多一层保障。红绿灯亮起时，你就知道该往前走，还是该踩刹车。