Spring Boot 06: what tests prove, from debugging to JAR and WAR

What should you trust more after mvn test passes? “The entire system works” is too broad. Read the assertions to identify their scope, then ask what remains unverified when startup or deployment changes.

Identify the environment created by the test

@SpringBootTest(properties = {
    "spring.datasource.url=jdbc:h2:mem:bootlab-test;DB_CLOSE_DELAY=-1",
    "lab.label=test-label"
})
@AutoConfigureMockMvc
class LabIntegrationTest {
    // See the download for injected fields and complete tests.
}

@SpringBootTest loads the application context. MockMvc exercises MVC handling inside the process without establishing a real TCP listener. This lab uses its real service and H2 JDBC rather than mocking the entire chain, so it observes writes but does not verify EAP, DB2, or MQ integration.

Read assertions, not only test names

mvc.perform(post("/api/tickets")
        .contentType("application/json")
        .content("{\"title\":\" \"}"))
    .andExpect(status().isBadRequest())
    .andExpect(jsonPath("$.code").value("INVALID_REQUEST"));
assertThat(count()).isZero();

This excerpt checks the blank-title response and the absence of writes. A rejected response alone would miss accidental persistence. The successful-create test separately checks 201, Location, the returned id, and a follow-up read. Dynamic ids are checked through relationships rather than compared to a fixed value.

The lab includes eight integration tests; its VALIDATION.md records execution evidence. A test count is not a coverage percentage or a guarantee for all inputs. Date, permission, or retry changes require corresponding cases rather than relying on the existing eight.

Fix the case and artifact before debugging

Record the input, settings, artifact, response, and data result. Find the earliest boundary that differs from expectations. For startup exceptions, inspect the relevant nested cause rather than treating “context failed” as the diagnosis. Change one cause and repeat the same case to connect the fix to the outcome.

mvn test
mvn package
java -jar target/boot-learning-lab-1.0.0.jar --server.port=8081
# Another terminal:
curl -i http://127.0.0.1:8081/api/ping

JAR and WAR change some runtime responsibilities

This project packages an executable JAR whose main starts an embedded server. A traditional WAR is loaded by an external Servlet container; Boot’s documented setup includes SpringBootServletInitializer, WAR packaging, and provided container dependencies. Renaming the file is insufficient. The download implements only the JAR path, not an EAP-tested WAR.

On EAP, check the listener and context root, then data source/JNDI, transaction manager, logging, and loaded libraries. server.port does not reconfigure EAP’s listener. Boot 3.5’s Servlet requirement is only one condition; vendor support and application modules require separate checks.

Exercise: write a handoff you can explain

Suppose lab.max-title-length changes from 80 to 100. Predict which test fails and whether the table can still store the value. Write the behavior change, configuration location, test adjustment, and remaining integration limits—not just “configuration updated, tests passed.”

Answer: change the 81-character case without removing its purpose

The old 81-character rejection should become acceptance. Check the new boundary at 100 and 101, retaining the no-write assertion on failure. The table’s 200 limit is not reached, but a legacy contract capped at 80 would still change. The learning objective is connecting intent, code, and evidence.