为DAO编写测试

Question

我目前被指派为项目编写测试，是否有必要为DAO类编写测试？

Answer 1

取决于： - ）

如果你的DAO类只包含从数据库中获取实体所需的代码，最好在单独的集成测试*中测试它们。要进行单元测试的代码是“业务逻辑”，您可以使用模拟DAO进行单元测试。

[更新] 例如使用EasyMock，您可以轻松地为特定类设置模拟（具有类扩展，甚至可以模拟具体类），将其配置为从特定方法调用返回特定对象，并将其注入到您的类中待测试。

EasyMock网站现在似乎已经关闭了，希望很快就会回来 - 然后你可以查看文档，这是恕我直言，非常干净和彻底，有很多代码示例。在你的问题中没有太多细节，我无法给出更具体的答案。的 [/更新]

如果，OTOH，DAO也包含业务逻辑，那么你的最佳选择 - 如果你能做到 - 将重构它们并将业务逻辑从DAO中移出，那么你可以应用之前的策略。

但最重要的是，始终牢记单元测试的座右铭“测试可能会破坏的一切”。换句话说，我们需要优先考虑我们的任务，并集中精力编写测试，以最少的努力提供最大的好处。首先为最关键，最危险的代码部分编写单元测试。代码 - 在您看来 - 如此简单，它不可能破坏在列表的下方。当然，最好咨询经验丰富的开发人员，了解具体的代码 - 他们可能知道并注意到您可能不知道的陷阱和问题。

* 单元测试应该是轻量级的，快速的并且尽可能地与环境隔离。因此，包括对真实数据库的调用的测试不是单元测试，而是集成测试。尽管从技术上讲它们可以使用JUnit（例如DbUnit）构建和执行，但它们要比正版单元测试复杂得多，并且要慢几个数量级。有时，这使得它们不适合在每次小代码更改后执行，因为常规单元测试可以（并且经常应该）使用。

Answer 2

是的，你应该为DAO编写单元测试。

这些单元测试可以使用内存数据库。例如，请参阅：HyperSQL

关于如何使用HyperSQL在Java中编写持久性单元测试的文章：

http://www.mikebosch.com/?p=8

Answer 3

是。但很少有人会认为，它不属于单元测试的范畴。因为它不符合单位测试的定义。我们称之为集成测试，我们测试代码与数据库的集成。

此外，我同意布鲁诺的想法。此外，还有可用的API，一个是DBUnit。

Answer 4

为任何事情编写测试都不是必要。您为DAO课程编写测试获得好处吗？可能。

Answer 5

是。这样做有几个好处。一旦确定DAO层工作正常，后续阶段的缺陷修复就变得容易了。

Answer 6

我认为我们应该为DAO编写单元测试，其中最大的挑战之一是测试数据设置和清理。这就是我认为，Spring JDBC测试框架之类的框架可以通过让我们使用不同的注释来控制事务来帮助我们[例如：@Rollback（true）]。

例如，如果您正在测试“创建/插入”操作，Spring允许您在执行测试方法后完全回滚事务，从而始终使数据库保持原始状态。

您可以查看此链接以获取更多信息：Spring Testing

对于您不希望一个测试破坏数据完整性的集成测试，这可能会更有用，这可能导致另一个测试失败。

Answer 7

本书xUnit Test Patterns为这个问题提供了很多很好的见解。