DAO单元测试

Question

我一直在关注使用它进行单元测试DAO类的EasyMock和教程/示例,用于"外部容器"测试.但是,我认为他们中的大多数都在谈论测试服务层,而不是模拟DAO类.我有点困惑,你真的是如何对DAO层进行单元测试吗？

有人会说,与DB和EJB交互的测试实际上是集成测试而不是单元测试,但是你怎么知道你的SQL是否正确(假设没有ORM)并且你的DAO插入/查询真实的正确数据(读取,本地数据库与生产中的数据库类似？

我读到DBUnit是这种情况的解决方案.但我的问题是使用像DBUnit这样的框架"外部容器".如果DAO依赖于某些EJB,我们如何处理事务,如果有更新其他表的触发器会发生什么？

仅对具有此类依赖性的DAO进行单元测试的最佳方法是什么？

Answer 1

就个人而言,我通过点击某种测试数据库对单元测试DAO,最好是你的应用程序在生产中使用的相同类型的数据库(显然不是SAME数据库).

我认为如果你这样做,测试更多的是集成测试,因为它依赖于正在运行的数据库.这种方法的好处在于它尽可能接近您正在运行的生产环境.它有缺点,您需要测试配置,您需要一个运行测试数据库(您的机器本地或您的环境中的某个地方),测试可能需要更长的时间来运行.您还需要确保在执行测试后回滚测试数据.

一旦DAO经过测试,肯定会嘲笑他们对您的服务进行单元测试.

Answer 2

通常使用DAO的想法是在数据访问代码周围有一个最小的包装器,因此除了映射到数据库之外没有什么可以测试,并且使用模拟的单元测试是无用的.如果DAO中的实际逻辑值得使用模拟进行测试,则可能会导致您滥用DAO模式并且逻辑应该在服务中.

为了测试到数据库的映射,DBUnit非常有用,因为它允许您在测试之前指定一个起始数据集,以便您的测试从已知状态开始,并且它允许您指定数据的结束状态应该是什么,因此您不必不得不写很多单元测试代码来断言有什么是预期的.

理想情况下,如果你有一个像Hibernate这样的工具来抽象数据库,你可以使用像H2或HSQLDB这样的内存数据库,这样你的测试运行得更快,而且没有数据库可以创建.如果您必须使用真实数据库,请确保您的测试自己拥有,以便他们可以创建和删除数据,而不会影响或受其他进程的影响.实际上,在本地和CI环境中都有自己的数据库是不可能的,并且使用内存数据库更加实用.