Found while following the skill on a Jmix 3.0.0 project.
Problem: silent — no mention of in-memory-database sharing across contexts.
Task
An integration test for a component that seeds reference data once (guarded by "does at least one Employee exist"), plus a companion idempotency test calling the seeding method twice.
Where
"Integration Test Pattern" / "Cleanup Audit" — the steps that use @SpringBootTest with an in-memory test datasource and clean up in @AfterEach.
What happened
The project's test datasource is jdbc:hsqldb:mem:<fixed-name>. HSQLDB's mem: protocol registers the catalog by name for the JVM's lifetime, so every @SpringBootTest class (and every @Test within a class, since they share one cached context) resolving to the same JDBC URL reads and writes the same database, not a fresh one per class or method. A test calling a seeding method twice in one method, expecting the second call to be a no-op because "the database starts fresh", instead hit a unique-constraint violation from its own first call's leftover rows. A second, unrelated test class later in the same Gradle test JVM then failed too, seeing the leftover rows and mis-evaluating its own "is the database empty" precondition. Caught by a clean test run.
Suggested fix
Add a line under "Gotchas"/"Cleanup Audit": an in-memory datasource with a fixed name is shared for the whole JVM/test run across all @SpringBootTest contexts that use it — not reset per class or method — so (a) @AfterEach cleanup is mandatory even for a "read-only" test, because a later test will otherwise see its leftover rows, and (b) a test invoking the same method twice in one body to prove idempotency must not assume a fresh precondition between the calls; set up explicitly the precondition the code under test actually checks.
Found while following the skill on a Jmix 3.0.0 project.
Problem: silent — no mention of in-memory-database sharing across contexts.
Task
An integration test for a component that seeds reference data once (guarded by "does at least one
Employeeexist"), plus a companion idempotency test calling the seeding method twice.Where
"Integration Test Pattern" / "Cleanup Audit" — the steps that use
@SpringBootTestwith an in-memory test datasource and clean up in@AfterEach.What happened
The project's test datasource is
jdbc:hsqldb:mem:<fixed-name>. HSQLDB'smem:protocol registers the catalog by name for the JVM's lifetime, so every@SpringBootTestclass (and every@Testwithin a class, since they share one cached context) resolving to the same JDBC URL reads and writes the same database, not a fresh one per class or method. A test calling a seeding method twice in one method, expecting the second call to be a no-op because "the database starts fresh", instead hit a unique-constraint violation from its own first call's leftover rows. A second, unrelated test class later in the same Gradle test JVM then failed too, seeing the leftover rows and mis-evaluating its own "is the database empty" precondition. Caught by a clean test run.Suggested fix
Add a line under "Gotchas"/"Cleanup Audit": an in-memory datasource with a fixed name is shared for the whole JVM/test run across all
@SpringBootTestcontexts that use it — not reset per class or method — so (a)@AfterEachcleanup is mandatory even for a "read-only" test, because a later test will otherwise see its leftover rows, and (b) a test invoking the same method twice in one body to prove idempotency must not assume a fresh precondition between the calls; set up explicitly the precondition the code under test actually checks.