在 Spring Boot 单元测试中，使用 H2 内存数据库时，GenerationType.IDENTITY 的自增 ID 不会随 deleteAll() 重置，导致断言失败；应避免断言完整实体对象，转而校验业务字段（如 authority），确保测试稳定、高效且与数据库实现解耦。
在 spring boot 单元测试中，使用 h2 内存数据库时，`generationtype.identity` 的自增 id 不会随 `deleteall()` 重置，导致断言失败；应避免断言完整实体对象，转而校验业务字段（如 `authority`），确保测试稳定、高效且与数据库实现解耦。
H2 数据库的 IDENTITY 列（对应 JPA 的 GenerationType.IDENTITY）在内存模式下不会因 TRUNCATE 或 DELETE FROM 而重置序列值——它仅在数据库连接关闭或显式执行 ALTER TABLE ... ALTER COLUMN id RESTART WITH 1 时才归零。因此，即使你在 @AfterEach 中调用 roleDao.deleteAll()，下一次 saveAll() 插入的实体仍会从上一个最大 ID 继续递增（如 id=3, id=4），而非期望的 id=1, id=2。这并非 Bug，而是 H2 对“内存表序列”的标准行为。
直接重置序列虽可行（例如通过 @Sql 执行 ALTER TABLE roles ALTER COLUMN id RESTART WITH 1），但会引入数据库耦合、降低可移植性，且需额外配置脚本路径与执行时机。更优解是：回归测试本质——验证业务逻辑，而非数据库实现细节。
✅ 正确做法：聚焦领域属性，忽略技术性 ID
你的测试目标是验证 findByAuthority 是否能根据权限字符串准确查到对应角色，而非确认其 ID 恰好为 1 或 2。ID 是数据库生成的内部标识，对业务无语义意义，也不应成为测试断言的焦点。
以下是重构后的测试示例（使用 AssertJ + Java Stream）：
@Test
void findByAuthority() {
Role result = roleDao.findByAuthority("USER");
assertThat(result).isNotNull();
assertThat(result.getAuthority()).isEqualTo("USER");
}
@Test
void findByAuthorityOrAuthority() {
List<role> results = roleDao.findByAuthorityOrAuthority("USER", "ADMIN");
assertThat(results)
.extracting("authority") // 安全提取 authority 字段（支持 null 安全）
.containsExactlyInAnyOrder("USER", "ADMIN");
}</role>
? 提示：
extracting("authority")比手动map(Role::getAuthority)更简洁，且自动处理 null；containsExactlyInAnyOrder确保结果包含且仅包含指定值（顺序无关），比contains()更严格，避免漏判多余数据。
⚠️ 注意事项：
-
勿依赖插入顺序或 ID 值做断言：JPA/Hibernate 不保证
saveAll()后实体 ID 的绝对顺序（尤其并发场景），且 H2 序列行为与 PostgreSQL/MySQL 可能不同； -
避免
@DirtiesContext过度使用：虽然@DirtiesContext(classMode = AFTER_EACH_TEST_METHOD)能强制重建上下文并重置 H2 状态，但会导致 Spring Context 频繁刷新，显著拖慢测试套件（通常增加 5–10 倍耗时），违背快速反馈原则； -
如需完全隔离状态，优先考虑
@Transactional+@Commit（慎用）或测试专用 Schema 初始化脚本，但绝大多数 DAO 测试无需此复杂度。
总结：测试应面向契约（Contract），而非实现（Implementation）。只要 authority 正确、关联关系符合预期、约束被遵守，ID 的具体数值就属于数据库内部机制，无需关心。这种设计让测试更健壮、可维护，并自然兼容生产环境使用的任何数据库（如 PostgreSQL、MySQL），真正实现“写一次，随处运行”。
