数据访问的单元测试
搜索了一下“数据访问层如何做单元测试？”，还真的有很多广大社区网友的心得。
JAVA的数据访问层其实可以写单元测试，但测完之后就不会有变化。
因为数据访问层本就不允许包含业务逻辑，写一个测一个删一个，留着没有意义，正儿八经留着还会增加额外工作量。
1、编写测试用例，包含了初始化测试环境的数据，测试目标代码，最后清空数据。
这种方法看似很规范，其实初始化测试环境的数据时都有可能报错，你写的时候测试是通过了，但你无法控制其他成员不操作数据库导致环境发生改变，一段时间后回过头再运行单元测试不一定能通过。
2、H2内存数据库单元测试。
比上面多了一步创建一段脚本建表。独立于测试环境的内存数据库，不用担心环境被改变。
但存在数据库脚本同步的问题，表结构调整要随时更新脚本。
3、Hibernate工具映射生成数据库。
比上面好一点，解决了同步问题，以领域模型为主，而不以数据库表结构为主。
但是必须是Hibernate，还得切换配置文件数据连接字符串，没切完蛋了。
最佳的实践是：数据库有变化，就测试相关的DAL，测试完就删除/注释用例和测试产生的数据。
因为我们的DAL里并不会包含业务逻辑，任何业务逻辑，只关心几张表之间自己的事情，只要表结构不动，就没必要重新测。
难点就是不包含任何业务逻辑。
举个例子：
SELECT * FROM [TABLE] WHERE STATE=1
这段SQL语句里其实就包含了一定业务，STATE=1。
DAL其实需要明白STATE=1是什么意思，如果化解？如下
SELECT * FROM [TABLE] WHERE STATE=:STATE
让STATE=1是什么意思让上面的业务层去解释。
业务逻辑的单元测试
要求业务逻辑层能独立运行，不允许依赖数据访问层。
许多人一开始就理解错误了，以为三层架构是WEB引用BUSINESS引用DAL，这是误传。
其实三层架构只是大致分为WEB / BUSINESS / DAL三层，相对于桌面应用程序两层架构 CLIENT/SERVER 来说的。
实际操作过程中，会用到依赖反转让DAL依赖BUSINESS，BUSINESS只依赖数据访问接口。
BUSINESS只能包含业务逻辑，不能去依赖其他层了，不然难以TDD DDD。
原理明白了，我们单元测试还是跑不起来，因为运行时会告诉我们数据访问接口没有实现。
这里最佳的实践是：用MOCK模拟数据访问接口实现，定义入参和返回值，单独测试业务逻辑。
mockito
@Mock
SsoTokenRepository ssoTokenRepository;
@Mock
SsoSessionRepository ssoSessionRepository;
@InjectMocks
AuthorizedService authorizedService;
@Test
public void getAccessToken() throws Exception {
//定义返回值
SsoToken result= new SsoToken();
result.setToken("123");
//定义入参
final String accessToken="444";
when(ssoTokenRepository.get(anyString())).thenReturn(result);//模拟一个仓储伪类
SsoToken ssoToken = authorizedService.getAccessToken(accessToken);
verify(ssoTokenRepository).get(accessToken);//验证模拟的伪类有没有被执行到
assertEquals(result.getToken(),ssoToken.getToken());
System.out.println(result.getToken());
}
这样在项目的任何阶段都可以重现单元测试，并且可以作为CMMI评审的测试用例。
原文地址：https://www.cnblogs.com/13yan/p/9158895.html