⭐ Testing Strategy

Four test layers run together here — context boot, unit with mocked collaborators, @DataJpaTest repository tests, and in-process gRPC/real-Docker wire integration — each blind to a different failure mode, each with a real bug example only it could have caught. See the testing-strategy.html diagram for the full breakdown.

Two things worth knowing that the diagram doesn't have room for:

A pattern across three separate JDK-25 incidents. Lombok, Mockito/ByteBuddy, and Spring Boot's own resolveMainClassName task all failed under JDK 25 for the same underlying reason: each reads or generates JVM bytecode via a bundled ASM/ByteBuddy version that predates JDK 25, and Spring Boot 3.4.1's dependency management consistently pinned the pre-JDK-25 version of each. Any new bytecode-touching tool added to this repo should be assumed to need the same treatment (an explicit version pin) until proven otherwise.

Bumping a BOM-managed version isn't always enough on its own. Fixing the Mockito/ByteBuddy incompatibility needed pinning mockito-core and byte-buddy explicitly — Spring's BOM kept forcing ByteBuddy back down even after the Mockito bump alone, since the BOM's constraint can outrank what the newly-bumped library itself declares it needs.