TDD 三定律
- 定律一 在编写不能通过的单元测试前 不可编写生产代码
- 定律二 只可编写刚好无法通过的单元测试 —— 测试临界
- 定律三 只可编写刚好足以通过当前测试的生产代码
测试与生产代码一起编写 测试只比生产代码早写几秒钟
保持测试整洁
- 命名
- 短小
- 具有描述性
- 设计良好
- 仔细划分
脏测试 = 没测试 测试不能保持整洁 你就会失去它们
因为测试必须随着生产代码的演进而修改 脏测试导致测试成为不断翻番的债务 不断恶性循环
没有了测试
- 失去确保对代码的改动如愿工作的能力
- 无法确保对系统某个部分的修改不会影响到系统的其它部分
并非出自有意的故障率上升 —— 害怕改动带来的损害多于收益 不再清理生产代码 —— 生产代码开始腐坏 —— 纷乱而缺陷缠身的代码 沮丧的客户
测试代码和生产代码一样重要
测试带来一切好处 因为测试使改动变得可能 单元测试 —— 无后患地对代码进行修改 —— 代码可扩展 可维护 可复用
整洁的测试
整洁测试三要素:可读性 可读性 可读性 —— 单元测试可读性比生产代码还重要
如何做到可读?让测试具有表达力并且短小精悍
- 明确
- 简洁 只用到那些真正需要的数据类型和函数 不至于被细节误导或吓倒 每个测试都清晰地拆分为三个环节(构造—操作—检验 )
- 构造测试数据
- 操作测试数据
- 检验操作是否得到期望的结果
- 足够的表达力
- 在命名上下功夫 不好理解的逻辑封装成一个语义化函数 一看就知道干了什么
每个测试一个断言
单个测试中的断言数量应该最小化
每个测试函数只测试一个概念
F.I.R.S.T
- Fast 快速 —— 方便频繁测试
- Independent 独立 —— 避免依赖
- Repeatable 可重复 —— 不挑环境
- Self-Validating 自足验证 —— 应该有布尔输出 而不是依赖日志主观判断测试是否通过
- Timely 及时 —— 测试应及时编写