本讲目的：
引出一些概念，总体的了解单元测试，具体实践后续补充；

单元测试的价值

定义：单元测试是一种白盒测试技术，通常由开发人员在编码阶段完成
目的：验证软件代码中的每个单元（方法或类）是否符合预期，尽早在尽量小的范围内暴露问题。
价值：问题发现得越早，修复的代价越小。

单元测试的类型

从开发的视角：

项目分层

• Controller：对外暴露http接口层，主要用于接受请求参数
• Service：一般用于业务逻辑的处理
• Dao：对数据库表进行操作，是最原子的操作
  当然在mybatis体系下，一般也会有两层Mapper接口与Mapping，XML映射文件；
  不同层次的单元测试的思路也是不相同的；
  那么我们的单元测试对于这作用不同的三层，测试的行为也会有区别；之后会分章节去说明；

根据被测单元是否与其交互者隔离

（附带提一下）

• 社交型单元测试
• 孤立性单元测试
  区别：举个例子，在登录的时候需要拿用户的账号密码去数据库中进行匹配，如果有则登录成功，如果没有则登录失败；
  社交性单元测试：就会真正的去调用dao层执行sql语句查询数据库是否有这个用户
  孤立型单元测试：会使用测试替身去代替dao层的执行，会模拟dao层执行单元测试，而不会真正去执行sql语句。
  这里引出一个概念测试替身：这是一种在测试中使用对象代替实际对象的技术，常用的技术：
  桩代码：当在对象上调用特定的方法时，会对其进行硬编码(临时代码)的方式来代替真实代码提供固定响应。
  模拟代码(MOCKS):模拟代码跟桩代码类似，除了代替真实代码的能力之外，更强调是否使用了特定的参数调用了特定方法，因此，这种对象成为我们测试结果的基础。

如何开展单元测试？

1.确定使用单元测试的代码范围

单元测试很重要，一般关注复杂，核心模块代码或底层代码进行单侧即可

2.确定技术选型

一般有的技术：
单元测试框架：
- TestNG
- Junit
Mock代码框架：
- Mockito：https://site.mockito.org/
- jMock:
- Easymock
- Mock框架对比：
断言：
assertJ：
Hamcrest：
一般推荐：Junit+Mockito+assertJ
测试+模拟+断言

3.引入衡量单侧覆盖情况的代码覆盖率工具

覆盖率工具：
Jacoco：
Emama：
Cobertura：

4.接入持续集成工具

单元测试最佳实践

好的单元测试实践规则：（这就是目的）

1. 好的单元测试要符合 AIR特点：
   - Automatic（自动化）
   - Independent（独立性）
   - Repeatable（可重复）
   保证单元测试可以自动执行（使用mvn：test可以实现），释放手工介入
   在使单元测试可以重复执行，可以是得简单的用例高效地执行起来（类似dao层的单元测试，每次插入数据，如果不是本地环境，最好将单元测试插入或者修改的数据进行回滚掉）
   在追求用例的相互独立性
2. 常见的规范
   - 代码目录规范
   - 测试类命名规范
   - 测试方法命名规范
   - 测试数据要求：使用生产环境的测试数据保障有效性和多样性
   - 验证结果需符合预期
   - 代码要遵守BCDE原则：B：Border，边界值，循环边界，特殊取值，特殊时间，数据顺序等；E：Error，强制错误信息输入，并得到预期的结果；D：Desigin，与设计文档相结合；C：Correct
   - 实践风格：需要加注释，有两种实践风格：1.准备-执行-断言：先准备测试对象，触发执行，最后对输出和行为进行断言；2.给定-当-那么：给定某个上下文，当发生某些事情，期望某些结果
   - 必须能自动验证：使用断言assert，不能使用System.out人工来判断