数据访问的单元测试

搜索了一下“数据访问层如何做单元测试？”，还真的有很多广大社区网友的心得。

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评审的测试用例。

 后面是给代码美颜：