测试驱动开发写测试用例：从零开始理解TDD实践

什么是测试驱动开发

测试驱动开发（TDD）是一种先写测试，再写代码的开发方式。听起来有点反直觉——还没写功能就先写测试？但这种方式能让人更清晰地思考需求。比如你做一个计算器，要实现加法功能，第一步不是写加法函数，而是先写一个测试，验证1加1是否等于2。

这种“先想结果，再动手”的思路，其实和生活中很多场景类似。就像做菜前先尝一口想象味道，或者装修前先看效果图。测试用例就是代码的“效果图”。

写第一个测试用例

假设我们要开发一个函数，判断一个数字是否为偶数。按照TDD流程，第一步是写测试。使用JavaScript配合Jest测试框架，可以这样写：

test('should return true when number is even', () => {
  expect(isEven(4)).toBe(true);
  expect(isEven(2)).toBe(true);
});

test('should return false when number is odd', () => {
  expect(isEven(3)).toBe(false);
});

这时候代码会报错，因为isEven函数根本不存在。这正是TDD希望看到的——测试失败。接下来的目标就是让测试通过。

让测试通过的最小实现

现在写最简单的代码让测试通过：

function isEven(n) {
  return n % 2 === 0;
}

运行测试，全部通过。这就是TDD的“红-绿-重构”循环：先写测试（红），再写代码让测试通过（绿），最后优化结构（重构）。整个过程像搭积木，每一步都有反馈。

测试用例的设计要点

写测试用例不是随便写几个例子。要考虑边界情况。比如判断偶数时，0算不算？负数呢？-4是不是偶数？所以应该补充这些测试：

test('should return true for zero', () => {
  expect(isEven(0)).toBe(true);
});

test('should handle negative even numbers', () => {
  expect(isEven(-4)).toBe(true);
});

如果发现原有代码不满足新测试，就要调整实现。这个过程逼着开发者把逻辑想得更完整。

TDD带来的实际好处

很多人觉得先写测试多此一举，但实际项目中，需求经常变。比如原来只处理整数，现在要支持小数。如果没有测试，改完后不知道会不会出问题。而有测试用例就像有了一份检查清单，每次修改都能快速验证。

团队协作时更明显。新成员接手代码，看不懂逻辑，但看测试用例就能明白每个函数该干什么。测试用例成了最准确的文档。

从小项目开始尝试

刚接触TDD不用强求全部代码都先写测试。可以从一个工具函数、一个表单验证开始。比如写一个邮箱格式校验函数，先列出测试场景：正常邮箱、缺少@符号、多个@符号、空字符串等。每个场景写一条测试，再逐个实现。

慢慢你会发现，写测试的过程就是在拆解需求。原本模糊的“要验证邮箱”变成了几条具体的规则，代码自然就清晰了。