C++升级之整洁之道（七）——驱动测试(TDD)

1.单元测试的缺点

  （1）一旦一个功能工作，用单元测试改进代码的动机很少；（2）结果代码很难测试；（3）通过改进的单元测试达到较高的测试覆盖率并不容易，完成代码后编程单元测试可能会导致漏掉某些问题或者bug。

2.驱动测试的流程

  组件、类以及函数从业务类基础的需求，TDD及其测试的第一种方法是通过单元测试确定需求——实际上，在编写代码之前，在测试第一种开发组件的方法中，这里指的是最底层的需求。
  其次，我们将编写一个测试，从而设计公共接口。这可能让人惊讶，因为在这个周期的一次允许中我们仍然没有编写任何产品代码，我们在测试在编写了一些代码之后，当然，我们还必须通过编译并提供测试所需要的接口。
  TDD周期通常被称为“红-绿-重构”

  红：我们编写的一个失败的测试案例；绿：我们编写产品代码。用于保证前面编写的测试用例通过；重构：删除重复代码以及其他代码的坏味道，重构代码包括产品代码和测试代码RED和GREEN指的是可以用于各种IDE的典型单元测试框架集成，其中通过的测试显示为绿色，失败的测试显示为红色。

3.TDD的优势

  1.如果遵循TDD的思想，在开发时就会逐步完成你的需求。传统方法的缺点在于，软件无法确保数小时或数天内的编译的执行不报错；2.TDD建立了一个非常快速的反馈循环，开发人员必须始终知道它们的代码的执行结果是否正确。3.先编写单元测试有助于开发人员思考接下来应该做什么；4.在TDD的帮助下，无间隙的规范可执行代码的形式出现；5.开发任意能够更加自觉和负责任地处理依赖关系；5.通常情况下，利用TDD开发的新产品代码将具有100%单元测试覆盖率。

  但是，系统的每一部分代码没有必要使用TDD进行开发，对于复杂性和风险很低，可以快速完成那些的代码，当然可以不使用TDD.，另一个挑战就是获得一个好的架构，不能取代度软件系统的粗粒度解耦的必要抉择。