测试驱动开发基础实践

测试驱动开发基础实践：别让“差不多”拖慢你的代码

写代码最怕的不是写错，而是“我觉得没问题”。我见过太多功能上线后才暴露问题：半夜报警、用户投诉、回滚发布。表面看是粗心，底子里其实是缺乏一套稳定的节奏。测试驱动开发（TDD）不是什么高深理论，它更像一种强制你慢下来、想清楚再动手的工作方式。先写测试、再写实现、最后重构，听起来绕路，实际上是在帮你把坑提前填平。

很多时候我们不是在写代码，而是在“补漏洞”

刚入行那会儿，我总喜欢先跑通主流程，再慢慢加判断。结果往往是功能跑起来了，边界却一塌糊涂。比如一个用户注册接口，我只测了“正常手机号能注册”，却没管格式错误、重复提交、超时重试。上线第一天，运营同事就发来截图：有人用“123”当手机号，系统直接报错却把敏感信息透出。那一刻我才意识到，问题不是技术多难，而是我没有把“异常”也当成正常路径来对待。测试驱动开发逼你先把异常写进测试用例，代码自然会更稳。

先写测试，其实是“先立规矩”

有人觉得先写测试是浪费时间，反正最后不还得测一遍？差别在于节奏。传统的“先写再测”容易变成“测不过就修，修过就行”，而TDD更像立规矩：我要这个函数做什么，在动手前就得说清楚。比如写一个计算折扣的函数，我先写下“满100减10”的测试。跑一遍，红。不是因为代码错了，是因为代码还没写。这时候我再去实现，刚好让测试变绿。这种“红灯—绿灯—重构”的循环，像游戏里的关卡，每一步都有明确目标，不容易跑偏。

案例：一条看似简单的库存扣减

我们做过一个库存扣减功能，最初的逻辑很简单：查库存、减库存、保存。后来上线发现并发出问题，同一商品被超卖。回过头看，不是技术实现多复杂，而是没把“并发”当成必须验证的场景。换成TDD的方式，我会先写一个测试：两个请求同时扣减，最终库存不能小于零。红灯亮起后，再考虑加锁或版本号。测试不只是验证结果，更是指引设计的方向。很多优化不是写到最后才想到，而是被测试“逼”出来的。

重构不是重写，而是“整理思路”

TDD的第三步常被忽略：重构。写完能跑的代码，很多人就直接提交。但测试驱动开发强调，在测试保护下整理结构：命名是否清晰、重复是否过多、依赖是否混乱。我见过一个订单状态机，if-else 套了四层，没人敢动。后来用TDD把每个状态变化写成测试，再逐步拆解成小函数。最后代码行数没少，但改一个状态只需要看一个函数。重构不是追求漂亮，而是让后来的自己不必“重新理解”。

别把TDD当成“银弹”，但值得当成习惯

当然，测试驱动开发不是万能的。界面交互、探索性原型、法规强控的场景，未必适合每行代码都先写测试。但它提供的思维方式很有价值：明确目标、控制风险、持续可验证。团队刚开始练时容易卡住：测试写不下去、总是改测试、节奏太慢。这时候不妨从小处开始，比如一个工具函数、一段校验逻辑，先走通“红灯—绿灯—重构”的完整循环。熟练后，你会发现写代码不再是“堆功能”，而是“搭结构”。

结语
测试驱动开发最迷人的地方，不在于测试本身，而在于它改变了你和代码的关系。你不再是边写边猜，而是先设标准、再逼近目标。错误被提前捕获，设计被持续打磨，协作也有了共同语言。少一些“我觉得没问题”，多一些“测试说可以”，代码才能走得更远。下一次写功能前，不妨先写一行测试，看看节奏会不会不一样。