Spring Boot 3.5 to 4 Verification Lab

Run the same application contracts on two pinned Spring Boot versions. Inspect HTTP security, an error dispatch that masks a CSRF rejection, a migration repair that leaves schemas different, and a test the default runner omits.

This is a synthetic teaching project created with AI assistance and executed during the site's October 2026 revision. It contains new source and observations; it does not recover earlier experiments or report a production incident. Recorded run: October 23, 2026, Java 17.0.19, Maven 3.9.11, macOS arm64.

Run it locally

Use JDK 17 or later, Maven and Python 3. The first build needs Maven repository access. No Docker or external database is required. Extract the ZIP and run these commands from its directory:

java -version
mvn -version
python3 verify.py

The script runs two passing suites and two fault demonstrations. It checks the failing test identity and assertion, so an infrastructure failure cannot count as a reproduced fault. Your raw logs go to verification-output/; the published evidence snapshot stays intact.

Recorded normal runs

Boot	Security	Flyway	H2	JUnit	Tests / failures / errors / skipped
3.5.7	6.5.6	11.7.2	2.3.232	5.12.2	11 / 0 / 0 / 0
4.0.0	7.0.0	11.14.1	2.4.240	6.0.1	11 / 0 / 0 / 0

Each normal command exited 0. These are the same eleven cases executed twice. The dependency profiles select historical comparison releases; they are not a recommendation about today's production patch.

Two failures the verifier requires

Discovery: explicit selection runs UndiscoveredShould and fails with DISCOVERY_SENTINEL. The two normal suites omit that class because its name is outside default patterns.
Error dispatch: disabling the fixture's permission for the servlet ERROR dispatcher produces real HTTP 401 where the network contract expects 403. The trace records the CSRF filter first rejecting with 403, then error authorization reaching the authentication entry point. Normal runs keep the narrow dispatcher permission and still require authentication for direct requests to /error.

Both fault commands executed one test, failed one assertion, and exited 1. CSRF stays enabled. The purpose is to demonstrate a detectable defect and its evidence, not to remove a test until Maven reports success.

Inspect the evidence before trusting the summary

The ZIP includes named JUnit XML reports. Machine paths and the local account name were redacted, and JUnit system properties were removed. Test identities, observed values and failures remain inspectable. The source digests cover the POM and application/test source; the record is not a third-party certification.

Source map

File	What to inspect
`pom.xml`	Two pinned dependency profiles and an explicit test runner.
`SecurityConfiguration.java`	Authenticated requests, CSRF protection, and the error-dispatch teaching switch.
`SecurityContractTest.java`	Six MockMvc cases, including an intentionally unsecured harness.
`NetworkContractTest.java`	Real loopback HTTP checks with Basic authentication and a protected direct /error request.
`DatabaseActivationTest.java`	A Flyway bean and the row its startup migration inserts.
`FlywayHistoryTest.java`	Edited migration history, metadata repair, and a forward corrective migration.
`UndiscoveredShould.java`	The deliberately failing test outside default discovery patterns.
`verify.py`	Commands, expected failures, named reports, redaction and source digests.

What these results cover

The fixture uses MockMvc, a real embedded server bound to loopback, and disposable H2 databases. The notes counter and database marker are intentionally small. Test users are synthetic; a separate network case exercises the public fixture credentials through HTTP Basic.

H2 results do not establish PostgreSQL/MySQL SQL semantics, locking, or production migration safety. The two profile runs use separate JVMs; they do not carry a persistent database across engine versions. The tests verify selected contracts, not every Boot 4 integration, an AI agent's performance, or an arbitrary application's upgrade.

Use the migration map to choose additional checks for your application, or return to the Java developer guide.