这也是很有启发性的一个章节，讲述了单元测试在系统开发中的重要性。

测试驱动开发（TDD）理论

测试驱动开发是近年来软件工程领域的一个新的最佳实践。它要求我们在定义了最上层的抽象结构（接口、抽象类或者一些方法的签名）之后，先编写对应的测试类，再去写业务代码的具体实现。

TDD三定律

这块其实还不太理解，先做记录，以后慢慢体会。

  • 先编写不能通过的单元测试，再编写生产代码；
  • 只编写刚好无法通过的单元测试，不能编译也算不通过；

  • 只编写刚好可以通过当前失败测试的生产代码。

    保持测试整洁

    不整洁测试代码的坏处

    如果测试代码不整洁，那么他们的可读性和可修改性就会很差。当生产代码演进时，测试代码随之变更的成本就会很高，这会导致测试代码逐渐脱节，进而导致生产代码的测试不足，错误率上升。
    如果测试代码足够整洁，那么它们的演进和维护成本就会更低，我们就可以随时保证生产代码可被测试，这就为生产代码的可扩展性提供了保障。

    整洁单测的要素

    整洁单测的核心要素就是——可读性，测试代码必须能够很容易的被其他团队成员或者后来人理解。

  • 测试代码也应该做合理的抽象——为了保证可读性和代码的整洁性，抽象出工具性的方法甚至类，这些方法或类具有良好的可读性，可以见文知义地了解到他们对应的业务含义（在表达了充足的业务信息的同时，也具备高度的概括性），这些方法和类就可以成为这一业务场景下的基础测试组件而被复用，进一步提高测试代码的编写效率；

  • 测试中一定要使用断言assert来实现自动化测试，而非以查看日志等方式来进行人工比对。不一定要限制每个单测只能有一个assert，但是，每个单测应该只测试一个具体的场景，同一个接口的多个场景应该使用多个测试方法来穷举（每个测试方法中使用一个独有的测试用例）。

    单测的FIRST原则

  • 快速Fast：单测的运行速度应该足够快，避免开发者“懒得运行”；

  • 独立Independent：每个测试方法应该互相独立，他们的执行应该顺序无关；
  • 可重复Repeatable：测试方法应该在任何测试环境中都有相同的表现，能通过的测试场景应该在任何环境中都保持可以通过的状态；
  • 自足验证Self-Validating：测试方法应该有布尔类型的输出，可以自动化判断是否通过，而非人工验证；
  • 及时Timely：单测应该及时编写，TDD原则要求我们先写单测再写实现。