skip to content

Explain why Failsafe defers test failures to the verify goal instead of failing during integration-test.

level: middleimportance: must knowfreq 60%

answer

  1. integration-test runs, verify judges
  2. failsafe-summary.xml
  3. teardown in post-integration-test must run
  4. forget verify = silent green
  5. mvn integration-test never fails

basics

~10 s

So teardown in post-integration-test always runs. The integration-test goal records results without failing; the verify goal later reads them and fails the build, after cleanup has happened.

solid answer

~40 s

Integration tests typically start external resources (a server, embedded DB, Testcontainers) in `pre-integration-test` and stop them in `post-integration-test`. If Failsafe failed the build the moment a test failed during `integration-test`, Maven would abort and skip `post-integration-test`, leaking those resources. So Failsafe's **`integration-test` goal** runs the tests and writes results to a summary file (`failsafe-summary.xml`) WITHOUT failing. Cleanup then runs in `post-integration-test`. Finally the **`verify` goal** reads the summary and fails the build if any IT failed. This guarantees deterministic teardown regardless of outcome. The cost: you must run `mvn verify` for failures to surface, and if you only bind `integration-test` (forgetting `verify`), failing ITs silently pass.

code

xml · 7 lines
xml
<execution>
  <id>integration-tests</id>
  <goals>
    <goal>integration-test</goal>
    <goal>verify</goal>
  </goals>
</execution>

go deeper

for a junior

Knows failures show up at verify, not earlier.

for a middle

Explains the summary-file mechanism and why teardown is protected.

for a senior

Spots the only-integration-test-bound bug and reasons about CI resource leaks.

for a principal

Designs setup/teardown bindings as a reusable convention across modules.

## The lifecycle phases involved Maven's default lifecycle has, in order around testing: `test` -> `package` -> `pre-integration-test` -> `integration-test` -> `post-integration-test` -> `verify` -> `install` -> `deploy`. Failsafe binds **two goals** to two different phases: - `integration-test` goal -> `integration-test` phase: **runs** the tests. - `verify` goal -> `verify` phase: **checks** the results and **fails** the build if needed. ## Why not fail immediately Consider a typical integration test that needs a running web server: - `pre-integration-test`: start the server (e.g. via cargo/jetty/Testcontainers). - `integration-test`: hit the server with tests. - `post-integration-test`: stop the server. Maven's rule: when a goal fails, the build aborts and **later phases do not run**. If the `integration-test` goal failed on the first broken test, the `post-integration-test` teardown would be skipped — the server keeps running, ports stay bound, containers leak. On CI this accumulates zombie processes; locally it blocks the next run. Failsafe's design: the `integration-test` goal **never throws on test failure**. Instead it writes a machine-readable summary, typically `target/failsafe-reports/failsafe-summary.xml`, recording pass/fail counts. Cleanup runs. Then the `verify` goal reads that summary and *only then* throws a build failure. ## The trap Because failure surfaces only in `verify`: - You must run `mvn verify` (or a later phase). `mvn integration-test` runs the tests but never fails even if they're broken. - You must bind BOTH goals. Binding only `integration-test` means tests run but are never verified — broken ITs report success. Always bind `integration-test` AND `verify` in the same execution. ## Configuration that ties cleanup to phases ```xml <plugin> <artifactId>maven-failsafe-plugin</artifactId> <version>3.2.5</version> <executions> <execution> <id>integration-tests</id> <goals> <goal>integration-test</goal> <goal>verify</goal> </goals> </execution> </executions> </plugin> ``` Teardown plugins (e.g. an embedded server plugin) bind their stop goal to `post-integration-test`, so it always runs before `verify` adjudicates.

  • What happens if you bind only the integration-test goal and not verify?
    Tests run but their failures are never checked, so the build stays green even when integration tests fail. Always bind both goals.
  • Where does Failsafe store the deferred result?
    In a summary file, typically target/failsafe-reports/failsafe-summary.xml, which the verify goal reads.

saying these in an interview costs you the question

  • Saying the integration-test goal fails the build on a failing test.
  • Omitting the verify goal and assuming failures still break the build.
  • Claiming teardown runs even after a fail-fast abort (it doesn't).

context

resolving links…