9 单元测试

TDD 三定律

• 定律一 在编写不能通过的单元测试前 不可编写生产代码
• 定律二 只可编写刚好无法通过的单元测试 —— 测试临界
• 定律三 只可编写刚好足以通过当前测试的生产代码

测试与生产代码一起编写 测试只比生产代码早写几秒钟

保持测试整洁

• 命名
• 短小
• 具有描述性
• 设计良好
• 仔细划分

脏测试 = 没测试 测试不能保持整洁 你就会失去它们
因为测试必须随着生产代码的演进而修改 脏测试导致测试成为不断翻番的债务 不断恶性循环

没有了测试

• 失去确保对代码的改动如愿工作的能力
• 无法确保对系统某个部分的修改不会影响到系统的其它部分
  并非出自有意的故障率上升 —— 害怕改动带来的损害多于收益 不再清理生产代码 —— 生产代码开始腐坏 —— 纷乱而缺陷缠身的代码 沮丧的客户

测试代码和生产代码一样重要
测试带来一切好处 因为测试使改动变得可能 单元测试 —— 无后患地对代码进行修改 —— 代码可扩展 可维护 可复用

整洁的测试

整洁测试三要素：可读性 可读性 可读性 —— 单元测试可读性比生产代码还重要
如何做到可读？让测试具有表达力并且短小精悍

• 明确
• 简洁 只用到那些真正需要的数据类型和函数 不至于被细节误导或吓倒 每个测试都清晰地拆分为三个环节(构造—操作—检验 )
  • 构造测试数据
  • 操作测试数据
  • 检验操作是否得到期望的结果
• 足够的表达力
  • 在命名上下功夫 不好理解的逻辑封装成一个语义化函数 一看就知道干了什么

每个测试一个断言

单个测试中的断言数量应该最小化
每个测试函数只测试一个概念

F.I.R.S.T

• Fast 快速 —— 方便频繁测试
• Independent 独立 —— 避免依赖
• Repeatable 可重复 —— 不挑环境
• Self-Validating 自足验证 —— 应该有布尔输出 而不是依赖日志主观判断测试是否通过
• Timely 及时 —— 测试应及时编写