Maven Test Execution Strategy: Ensuring Complete Test Runs Across All Modules

Dec 01, 2025 · Programming · 12 views · 7.8

Keywords: Maven test execution | multi-module project | -fae parameter

Abstract: This paper provides an in-depth analysis of test execution completeness in Maven multi-module projects. By default, Maven stops subsequent test execution when tests fail in a module, potentially leaving other modules untested. Through examination of Maven Surefire plugin configurations and command-line parameters, particularly the -fae (--fail-at-end) parameter's mechanism, this article presents solutions to ensure all tests are executed completely. The discussion includes differences between testFailureIgnore configuration and -fae parameter, along with best practice recommendations for various scenarios.

Analysis of Test Execution Mechanism in Maven Multi-module Projects

In Java multi-module projects built with Maven, test execution strategy requires careful technical consideration. By default, Maven's build lifecycle follows the "fail-fast" principle: when test cases fail in a module, Maven immediately stops the build process and does not execute tests in subsequent modules. While this design provides quick feedback on build failures, it may not be optimal in certain scenarios.

Root Causes of Test Execution Interruption

Maven's test execution is managed by the Surefire plugin. When the plugin detects test failures, it decides whether to continue execution based on configuration. Under default settings, any test failure causes build failure, which interrupts the entire build process. Even with <testFailureIgnore>true</testFailureIgnore> configured in pom.xml, this only ensures tests continue within the current module but cannot prevent Maven from stopping subsequent module builds due to build failure.

Core Mechanism of the -fae Parameter

Maven provides the -fae (or --fail-at-end) command-line parameter to address this issue. This parameter allows all non-dependent modules to continue test execution, evaluating build status only after all tests complete. Specifically:

  1. When tests fail in module A, Maven continues executing tests in module B
  2. If module B depends on module A, module B's build is skipped
  3. All tests in non-dependent modules are executed
  4. The final build report aggregates all test results

This mechanism ensures maximum test coverage even when some modules have failing tests.

Comparative Analysis of Configuration Methods

Beyond the -fae parameter, several other configuration approaches exist:

In practice, the -fae parameter is typically the optimal choice as it ensures test completeness while providing accurate build status feedback.

Practical Application Scenario Example

Consider a project structure with three modules:

project-root
├── module-core
├── module-service
└── module-web

Where module-service depends on module-core, and module-web depends on module-service. When using the standard command mvn test, if tests fail in module-core, the entire build stops immediately. With mvn test -fae:

  1. Test failures in module-core are recorded but don't stop the build
  2. module-service is skipped due to dependency relationships
  3. module-web continues test execution as a non-dependent module
  4. The final build report shows test results from both module-core and module-web

Best Practice Recommendations

Based on the analysis above, we recommend the following best practices:

  1. In continuous integration environments, use the -fae parameter to ensure complete test coverage reports
  2. For local development environments, choose whether to use this parameter based on specific needs
  3. When completely ignoring test failures is necessary (such as documentation generation scenarios), use the -fn parameter
  4. Clearly document test execution strategies in project README or build documentation

By properly configuring Maven's test execution strategy, development teams can ensure code quality while obtaining more comprehensive test feedback.

Copyright Notice: All rights in this article are reserved by the operators of DevGex. Reasonable sharing and citation are welcome; any reproduction, excerpting, or re-publication without prior permission is prohibited.