测试驱动开发从零开始：写代码前先写测试，真的不难

小王刚改完一个 Bug，测试一跑，又崩了三个地方。他挠着头想：为什么每次修一个，倒下一片？

隔壁工位的老李没吭声，敲了几行测试代码，再写功能逻辑，跑通，提交，喝口茶——当天的需求就稳稳上线了。

测试驱动开发，不是给测试人员写的

TDD（Test-Driven Development）不是让程序员去干测试工程师的活，而是把“验证逻辑是否正确”这件事，提前到写功能代码之前。它就三步，像煮面一样简单：

1. 红：写一个会失败的测试（还没功能，当然红）
2. 绿：写最简代码让它通过（能跑就行，别想太多）
3. 重构：优化代码结构，测试必须还绿

反复循环，代码就像搭积木，一块一块垒得踏实。

动手试试：用 Python 写个加法函数

假设我们要做一个支持整数相加的 add 函数。别急着写函数，先写测试：

import unittest

class TestAdd(unittest.TestCase):
    def test_add_two_positive_numbers(self):
        self.assertEqual(add(2, 3), 5)

    def test_add_negative_and_positive(self):
        self.assertEqual(add(-1, 1), 0)

这时候运行 python -m unittest test_add.py，报错：NameError: name 'add' is not defined——对，这就是“红”的状态。

现在才开始写最简实现：

def add(a, b):
    return a + b

再跑测试，全部通过——“绿”了。如果后续要支持字符串拼接，或者限制输入类型，那就再加新测试、再改代码，每一步都有测试兜底。

刚开始容易踩的坑

• 别追求“一次性写对测试”：测漏了？补一个；测错了？改掉。测试也是代码，也要迭代。
• 别在测试里写复杂逻辑：比如用 for 循环生成 100 个断言——人脑容易晕，机器也难读。
• 别跳过重构这步：函数越写越多，发现 add 其实该叫 sum_integers，那就改，只要测试还绿，你就敢动。

有同事说：“我手写几个 print 就能看结果，干嘛写测试？”——那下次你改完代码，是靠人眼扫三遍日志，还是敲一下回车等 0.2 秒看绿色小勾？

TDD 不是银弹，但它确实让你少些心虚，多些笃定。从今天起，新建一个文件，先敲下 def test_，再写功能——你已经站在起点了。