TDD三定律

1. You must write a failing unit test before you write production code.
   单元测试代码先于生产代码
2. You must stop writing that unit test as soon as it fails; and not compiling is failing.
   单元测试一旦失败，开始写生产代码
3. You must stop writing production code as soon as the currently failing test passes.
   老测试一旦通过，返回写新测试

单元测试好处

单元测试让代码可扩展、可维护、可复用。原因很简单，有了测试，你就不用担心对代码的修改。如果没有测试，每次修改都可能带来缺陷。无论代码设计的多么符合规范，可扩展性多么强。如果没有测试，你就很难对代码做改动。因为人脑与计算机不同，它无法保证考虑到所有分支所有场景。

如何写好单元测试

可读性、可读性、还是tmd可读性。在单元测试中，代码的可读性甚至比生产代码还要重要。明确、简洁、并有足够的表达力。借用翻译的金标准，也就是尽力区做到“信达雅”。
测试一般可以分成3个环节：

• 构造 根据覆盖目标的不同和覆盖源程序语句的详尽程度，构造数据的覆盖方式又可分为： 语句覆盖(SC) 判定覆盖(DC) 条件覆盖(CC) 条件/判定覆盖(CC) 条件组合覆盖(MCC) 修正判定条件覆盖(MCDC) 点覆盖 边覆盖 路径覆盖。选取适合自己项目的覆盖方式。
• 测试 测试即使用构造数据输入待测试单元并运行的过程。
• 检验 校验是单元测试价值的真正体现。如果没有校验过程，那么一切构造、一切运行都没有意义。使用assert语句，判断输出是否符合预期。值得注意的是，False或者Error也是预期的一种。

单元测试原则

双重标准

单元测试与生产代码，分属不同场景。应遵循不同的工程标准。例如，生产代码是运行在嵌入式系统上，那么就要追求极简、高效，用于匹配嵌入式系统有限的资源。测试环境中完全没有必要考虑此类情况。重点是，代码整洁可读是所有代码共同的要求。

断言

有一种说法，每个测试函数都要有一个断言语句。这种规则看起来苛刻，实际上好处多多。首先是代码整洁可读，每个断言代表一个测试的结束。其次，在拦截意外之时，你的测试用例将更加有效。

F.I.R.S.T

• Fast(快速) 测试代码必须要能够快速运行。如果测试代码运行缓慢，则会成为开发的累赘。只有1min以内能跑完的测试，开发者才会频繁运行，从而从容清理错误代码。
• Independent(独立) 测试应相互独立。删除或增加用例不应对其他用例产生影响。如果测试用例相互依赖，一个用例出错会导致一连串的错误，定位将变得无比复杂。
• Repeatable(可重复) 测试应该能在任何环境在任何时间通过。如果测试不能永远正确，那么你就总有解释失败的借口。
• Self-Validating(自足验证) 测试用例应该有布尔输出，成功或者失败，绝不应该在日志中判断。
• Timely(及时) 测试用例应及时编写。就如TDD原则，在生产代码之前，测试代码就应该写完。

软件开发过程中，问题发现的越晚，修复成本就会越高。单元测试，是发现问题最早时机(如果不算代码检视的话)。做好单元测试，前期可能代码量将会增加一倍。但无论对于代码重构还是未来的代码维护，单元测试必然是无可或缺的一部分。