小王刚接手一个接口重构任务，改完一测，线上报500。他翻日志、加断点、反复试，两小时后才定位到是空指针——其实这个case，写个测试早就能拦住。
不是先写代码，而是先写失败的测试
测试驱动开发（TDD）不玄乎，就三步，像煮面一样简单：
① 红：写一个会失败的测试；
② 绿：写最少代码让测试通过；
③ 重构：优化代码结构，不改行为。
比如你要写一个函数，把用户昵称首字母大写：
def capitalize_name(name):
pass # 先空着第一步，写个明知道会挂的测试：
assert capitalize_name("alice") == "Alice"运行，红——报错或断言失败。第二步，只写够用的代码：
def capitalize_name(name):
return name.capitalize()再跑，绿了。第三步，看看有没有重复逻辑、变量名是否清楚、要不要加空值判断——这些动作都不影响测试结果。
为什么网络服务特别适合这三步？
HTTP接口、数据库交互、缓存调用……这些环节一旦出错，排查成本高、影响面广。TDD逼你在动手前就想清楚：输入是什么？期望输出是什么？边界在哪？
比如写一个校验token有效期的函数，你不会等到联调时才发现“过期时间传的是字符串没转int”——因为第一步的测试早就写了：
assert is_token_valid("abc123", "2025-03-15T10:00:00") == True
assert is_token_valid("abc123", "2020-01-01T00:00:00") == False测试即文档，跑得过，说明当前逻辑成立；哪天需求变了，改测试、再改实现，节奏稳得很。
别怕“多写一遍”，怕的是“不敢改”
很多开发者说：“我哪有时间写测试？”其实真正耗时间的是修bug、救火、猜逻辑。TDD省下的，是反复验证、口头对齐、凌晨三点上线回滚的时间。
三步法不是教条，是手感。今天写个工具脚本，先敲两行assert；明天调API，先mock响应写断言——习惯养成了，代码反而写得更快、更踏实。