领域驱动单元测试
数据访问的单元测试
搜索了一下“数据访问层如何做单元测试?”,还真的有很多广大社区网友的心得。
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评审的测试用例。