java - JUnit 和 Spring 的 DAO 层测试策略

Question

我正在尝试设计一种最佳策略来对我的 Spring 应用程序的 DAO 层进行单元测试。 许多现有的方法，如内存数据库使用等(帖子:12289800、12390813、9940010、12801926)。不要吸引我。

所以，这是我想到的一个简单的方法:

1. 创建 Spring test-context.xml 并将测试所有 DAO 类所需的所有数据放在那里；
2. 为每个测试类创建一个模板方法来测试 CRUD 操作和所有“选择”操作；
3. 在测试之前，将所有需要的数据从 test-context.xml 插入到您的真实数据库中。我们可能还需要一些依赖项(引用)，所以也插入它们，比如在 @Before 方法中。
4. 在所有 CRUD 操作之后，从数据库中删除所有依赖项(引用)，比方说在 @After 方法中。

如果我们有很多依赖项，这可能会成为一种非常昂贵和费力的方法。此外，我们只有一个 @Test 方法(模板方法，以确保操作顺序:创建、读取...等)- 因此每个测试类一个测试。

那么，我需要一个建议，这个策略是否可行？你做了哪些类似的事情来测试你的 DAO？

Answer 1

毕竟，我最终采用了这种策略来测试负责与基于 Spring 的应用程序中的数据库交互的类。主要思想:

1. 使用内存数据库(H2 可以)，一个带有测试数据源和设置的独立 Spring 配置文件。
2. 数据库是在整个测试过程开始时从 schema.sql 脚本中建立的。所以我们需要有sql源来重建测试数据库。如果您自己设计数据库，它可能来自 DBA 或您自己。如果您在大型团队中使用数据库，那么像 liquibase 或 flyway 这样的工具非常有用，每个人都需要通过应用增量脚本来了解数据库的实际状态。通过这种方式，结果设置脚本由该工具管理。
3. 显然，每个测试用例都需要在执行测试之前初始化自己的数据集。我们通过制作 sample.sql/clear_sample.sql 脚本(每个测试用例一对)来在每个用例前后插入和删除数据。为此，我们可以使用 spring 的注解:@Sql或 ScriptUtils
4. 为了帮助设计测试，我们可以注入(inject) EntityManager，例如在 sql 脚本的帮助下检索插入的内容。
5. 使用基本的 JUnit 断言进行比较。

因此，我们没有额外的软件层，如 DbUnit 或任何东西，而是编写隔离和可维护的单元测试。 不可避免的缺点是，当数据库或多或少发生重大变化时，我们需要重写整个测试，甚至重写几个测试。