小王刚接手一个用户登录功能，急着敲代码，不到一小时就写完提交了。结果第二天测试一跑，密码校验逻辑出错，邮箱格式没判断，连空输入都没拦住——他只好又切回去改，改完再测，反复三四轮才勉强上线。
为什么总在“补漏”？
很多新手习惯“先写功能，再补测试”，就像修房子先砌墙、最后才量尺寸。可代码不是砖头，逻辑一旦嵌套起来，改一处可能崩三处。等发现bug再回头查，往往已经忘了当初为啥这么写。
换个思路：先写测试，再写代码
测试驱动开发（TDD）的核心就一句话：动手写业务代码之前，先写一个会失败的测试用例。不是为了应付检查，而是帮你把需求想清楚、把边界划明白。
比如写一个加法函数，别急着实现 add(a, b)，先写：
test('add 应该返回两个数之和', () => {
expect(add(2, 3)).toBe(5);
});此时运行测试，必然报错——因为 add 根本还没定义。这个红灯就是你的起点。
红→绿→重构，三步走
1. 红（Red）：写一个明确预期的测试，让它失败（证明测试有效）；
2. 绿（Green）：用最简单、甚至“笨”的方式让测试通过（比如直接 return 5）；
3. 重构（Refactor）：在测试保护下，优化代码结构、命名、逻辑，确保每次改完都还是绿的。
还是加法例子，第二步你可能写成：
function add(a, b) {
return a + b;
}第三步可以加更多测试：负数、小数、字符串输入……每加一条，都先看到红，再让它变绿。代码不是越写越多，而是越写越稳。
有同事说：“我哪有时间先写测试？”其实真写起来，一个基础函数配两三个测试，也就一两分钟。省下的调试时间、返工时间、半夜救火时间，远不止这点。
在电脑工场搭积木式学编程，不追求快，而求每一块都扣得牢。TDD不是给代码上枷锁，是给脑子装导航——方向对了，路再绕也不怕迷。