如何编写数据库的单元测试？

本文目录导读：

1. 策略一：使用内存数据库（最推荐，快速且隔离）
2. 策略二：使用 Testcontainers（最真实，推荐集成测试）
3. 策略三：Rollback 模式（最简单，但需注意副作用）
4. 策略四：Mock 数据库层（最轻量，适合核心业务逻辑）
5. 核心注意事项（避坑指南）
6. 最终建议：选型原则

编写数据库单元测试的核心挑战在于隔离性和可重复性，你既希望测试真实SQL逻辑，又不想让它依赖外部数据库的当前状态。

以下是编写高质量数据库单元测试的四种主流策略,从最推荐到最轻量级排列：

使用内存数据库（最推荐，快速且隔离）

使用 H2、HSQLDB 或 SQLite 这类完全运行在内存中的数据库替代真实数据库。

优点：毫秒级速度，无需外部依赖，测试之间自动隔离（内存清理快）。 缺点：不同数据库对 SQL 的兼容性有细微差别（如 MySQL 的 FULLTEXT 索引），可能掩盖数据库特有的 Bug。

代码示例（基于 JUnit 5 + Spring Boot + H2）：

// 1. 测试配置
@DataJpaTest // 只加载JPA相关组件
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.ANY) // 自动替换为H2
class UserRepositoryTest {
    @Autowired
    private UserRepository userRepository;
    @Test
    @Sql(statements = "INSERT INTO users (id, name, email) VALUES (1, 'Alice', 'alice@test.com')") 
    void testFindByEmail() {
        // 执行
        User user = userRepository.findByEmail("alice@test.com");
        // 断言
        assertThat(user).isNotNull();
        assertThat(user.getName()).isEqualTo("Alice");
    }
}

关键点：@DataJpaTest + 内存数据库 = 测试不依赖外部 Docker 或真实数据库，速度极快。

使用 Testcontainers（最真实，推荐集成测试）

如果业务逻辑强依赖数据库特有的语法（如 PostgreSQL 的 JSONB 操作、MySQL 的 ON DUPLICATE KEY），用真实数据库容器测试。

优点：100% 兼容生产环境，能发现方言差异导致的 Bug。 缺点：需要安装 Docker，启动速度比内存数据库慢（秒级 vs 毫秒级）。

代码示例（Java + Testcontainers + JUnit 5）：

@Testcontainers // 自动管理容器生命周期
@SpringBootTest
class UserRepositoryTest {
    // 1. 定义PostgreSQL容器（启动一次，所有测试复用）
    @Container
    static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:15")
            .withDatabaseName("testdb");
    // 2. 动态覆盖数据源配置
    @DynamicPropertySource
    static void configureProperties(DynamicPropertyRegistry registry) {
        registry.add("spring.datasource.url", postgres::getJdbcUrl);
        registry.add("spring.datasource.username", postgres::getUsername);
        registry.add("spring.datasource.password", postgres::getPassword);
    }
    @Autowired
    private UserRepository userRepository;
    @Test
    void testSaveAndFind() {
        // 测试前，用@Sql或直接操作来清理数据
        userRepository.deleteAll();
        User user = new User(null, "Bob");
        userRepository.save(user);
        Optional<User> found = userRepository.findById(user.getId());
        assertThat(found).isPresent();
    }
}

关键点：@Testcontainers + @DynamicPropertySource = 测试自动连接真实数据库，测试完后容器自动销毁。

Rollback 模式（最简单，但需注意副作用）

利用数据库事务特性：每个测试方法运行在事务中，测试结束后自动回滚。

优点：代码改动最小，无需额外数据库。 缺点：无法测试提交后的持久化行为（如触发器、外键约束在提交时才完整生效）；如果测试中有异步操作，回滚可能失效。

代码示例（Spring Boot + @Transactional）：

@SpringBootTest
@Transactional // 每个测试方法结束后自动回滚
class UserRepositoryTest {
    @Autowired
    private UserRepository userRepository;
    @Test
    void testUpdateEmail() {
        // 插入一条模拟数据
        User user = userRepository.save(new User("Charlie", "old@test.com"));
        // 执行更新
        user.setEmail("new@test.com");
        userRepository.save(user);
        // 验证（在同一个事务中查询，能看到未提交的数据）
        User updatedUser = userRepository.findById(user.getId()).get();
        assertThat(updatedUser.getEmail()).isEqualTo("new@test.com");
        // 测试结束，事务回滚，数据自动消失
    }
}

警告：如果你的测试需要验证 INSERT ... ON CONFLICT 或手动 commit()，此方法不适用。

Mock 数据库层（最轻量，适合核心业务逻辑）

完全不访问真实数据库,使用 Mock 框架（如 Mockito）模拟 Repository 的返回值。

优点：毫秒级，彻底不依赖数据库。 缺点：无法验证 SQL 语法、索引、约束是否正确，适合测试业务服务层逻辑而非 SQL 本身。

使用场景：当你的服务层逻辑复杂（如条件判断、数据聚合），而数据库查询只是简单 CRUD。

@ExtendWith(MockitoExtension.class)
class UserServiceTest {
    @Mock
    private UserRepository userRepository;
    @InjectMocks
    private UserService userService;
    @Test
    void testGetUserEmail_Success() {
        // 模拟数据库返回
        User mockUser = new User("Alice", "alice@test");
        when(userRepository.findByEmail("alice@test")).thenReturn(Optional.of(mockUser));
        // 执行业务逻辑
        String email = userService.getUserEmail("alice@test");
        // 验证
        assertThat(email).isEqualTo("alice@test");
        verify(userRepository).findByEmail("alice@test"); // 验证确实调用了查询
    }
}

核心注意事项（避坑指南）

1. 始终隔离测试数据：不要依赖测试外的数据，每个测试前清理自己的数据（使用 @BeforeEach 或 @Sql 脚本）。
2. 设计可清理的测试数据：不要用自增 ID 硬编码，改用 findBy... 或唯一约束来定位。
3. 事务回滚 ≠ 测试通过：@Transactional 回滚后，测试提交后逻辑（如触发器、视图）可能无法被验证，此时用策略二更合适。
4. SQL 脚本管理：复杂场景用 @Sql(executionPhase = Sql.ExecutionPhase.BEFORE_TEST_METHOD, scripts = "classpath:test-data/user-setup.sql")。

最终建议：选型原则

最佳实践组合：

• 单元测试（服务层）：用 Mock（策略四），测试业务逻辑。
• 集成测试（数据层）：用 Testcontainers（策略二），测试 SQL 和执行计划。
• CI/CD 中的快速检查：用 H2 内存数据库（策略一）作为预检，再跑 Testcontainers 作为深度检查。

记住一个原则：不要测试数据库本身（那是数据库厂商的事），而是测试你的代码与数据库的交互是否正确。