自动化测试
目的
在频繁迭代中，通过自动化测试可以减少代码bug，保证代码能够按照预期跑通。自动化测试一开始是帮你找bug，后续的角色是进行安全检查。
自动化测试需要包括哪些内容呢？我觉得需要包含单元测试、集成测试、接口测试。
简要概括单元测试、集成测试、接口测试
- 单元测试：抛开所有外部依赖，验证单个函数的功能是否符合预期。
- 集成测试：在单元测试的基础上，测试多个函数组合起来是否按照预期。
- 接口测试：通过单元测试和集成测试验证了小功能，还需要通过接口测试验证整个链路是否按照预期执行。
自动化测试之单元测试
1. 单元测试的FIRST准则
- Fast：测试不能每跑一次都要耗费大量的时间。
- Independent： 测试与测试之间不应该存在依赖关系。
- Repeatable： 测试应该在任何环境下都能运行，不论是生产环境、测试环境，或者是在家里的笔记本电脑上。
- Self-Validating 测试的结果应该是显而易见的，不应该是靠人去查看它的输出才能判断测试的成功与失败，即使用断言来判断实际是否满足预期。
- Timely： 测试需要在正式代码之前就写好。
2. 单元测试的一些其他要求
- 单元测试Case就是文档，因为说明了输入和输出
- 每个case只测试单一函数的单一行为
- 测试用例的名称要清晰表明测试目的，如TestCreateOrder_Failed_Pid_NotExist
- 在编写正式代码之前，必须写出其相对应的单元测试；
这就是说一定要先写出一个单元测试（因为还没有编写正式代码，所以它肯定会失败），再编写正式代码。 - 只要一个单元测试失败了，就不要再编写任何更多的单元测试了；
而是要去编写相应的的可以使之通过的正是代码，编译失败也算； - 只要正式代码可以使单元测试通过，就不要再编写更多的正式代码了；
正式代码需要满足的唯一目标就是通过单元测试，只要通过单元测试，就表示我们此部分的代码已经写完了。
3. 单元测试的三段式
单元测试的三段式：
- 准备测试数据。
- 对测试数据进行操作。
- 进行判定。
3. 单元测试的三大模块
- 驱动模块：相当于所测模块的主程序。它接收测试数据，把这些测试数据传送给被测模块，最后再输出实测结果。
- 桩模块。由被测模块调用，用以代替由被测单元所调用的模块的功能，返回适当的数据或进行适当的操作使被测单元能继续运行下去，同时还要进行一定的数据处理，如打印入口和返回等，以便检验被测模块与其下级模块的接口
- 被测系统 SUT （System Under Test）
4. 测试替身 Test Double
前面提到了测试替身。
替身、依赖注入
+参数传入
+构造函数
+set函数
设计决定一切
测试替身有很多种：
- mock是测试替身的一种，复杂的一种
- 一般用mock来指定一个测试替身
- 为什么用mock object
- 返回一个数据
- 返回一个true/false 状态，可以使用一个测试替身
- 使用mock？是否按照预定顺序，是否执行？
测试与实现的顺序：
先写测试在写实现
持续集成
1. 持续集成Continuous integration
- 定义：频繁地（一天多次）将代码集成到主干。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成
2. 持续集成的整个过程分为几步：
- 代码提交
- 代码测试：代码仓库对commit操作配置钩子（hook），只要提交代码或者合并进主干，就会跑自动化测试。
- 构建：
- 第二轮测试：进行全面测试，包含单元测试、集成测试、全链路接口测试。以自动化为主，少数无法自动化的测试用例需要人工跑
- 部署
- 回滚
参考：
https://codeship.com/continuous-integration-essentials
http://codecloud.net/10516.html
http://www.uml.org.cn/test/201107085.asp
http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd