Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »



I am in the process of researching and documenting all the current solutions offline and tying together a more complete proposal that matches the criteria below. - Brett 26/Dec/07


There are currently a number of solutions for testing plugins - both in terms of unit testing and integration testing. This has resulted in a confusing situation where plugins can be tested in multiple different ways, and there are no clear instructions for a new plugin author in how to test their plugins.

The objective of this document is to assess all the current approaches, and their positives and negatives, and to provide a baseline for discussion about the various approaches. It will attempt to identify overlap and make proposals to reduce duplication and confusion. It will also attempt to document how to write integration tests for your plugin, depending on your objectives. It will not attempt to propose a single-replacement solution - as there are likely good reasons to have different types of testing, and a separation of different techniques into different plugins (though deprecation of some libraries or techniques to reduce duplication may be necessary).

Available Solutions

Unit Testing

Definition: This is traditional unit testing - it takes no consideration for the fact that it is a Maven plugin, and tests the code itself.

  1. maven-plugin-testing-harness: This library provides assistance for plugin testing by pre-constructing the Plexus components, providing stub objects for Maven functionality such as projects, and populating fields from an XML file that resembles the plugin configuration in the POM.
  2. standard JUnit testing: MOJOs written in Java can be tested using JUnit as standard Java objects (possibly using a mock framework to mock the Maven functionality such as projects). For non-Java MOJOs, a corresponding test framework may be used for that language but the same principles apply. Using the PlexusTestCase can also give some of the instantiation assistance of the testing harness without the stubs.

Integration Testing

Definition: Integration testing for plugins is checking that a plugin works with the Maven framework libraries in a given situation, but does not do and end-to-end functional test of a Maven project.

  1. ...

Functional Testing

Definition: Functional testing for plugins is running an entire Maven build that utilises a given plugin and verifies the output of the build process.

  1. ...

Smoke Testing

Definition: A form of functional test that would be run in the integration testing phases and checks base functionality for sanity.

Performance Testing

Definition: Performance testing is a specialised form of acceptance testing.







Runs with Surefire

Generates JUnit XML

Can measure coverage using standard techniques

Can be used for unit testing

Can be used for integration testing

Can be used for functional testing

Has a non-snapshot release

Has a non-alpha release

Has an archetype

Test without installation

Run tests against multiple versions

Forked Maven

Embedded Maven

Beanshell support

Groovy support

Suite setup steps

Suite teardown steps

Suite verification steps

Does not pollute source tree on execution

Does not pollute the local repository

Does not pollute the temporary directory

Isolated from user's environment/settings

Able to run from the IDE

Able to run offline (unless plugin requires it)

Can be used for testing non-Maven things

Can be used for Maven testing

Can be used for plugin testing

Can be used for report plugin testing

Tests plugin annotations

Able to run a single test

Able to run a suite of tests

Able to drop-in an IT easily from a user submission

Able to compile custom sources

Able to add custom dependencies

Able to run in a separate project

Able to run in the same project

Provides stub factories for creating Maven objects

Provides alternate remote repository handling

Fast execution

State of the Nation

  • IT plugin has grown out of date
  • verifier is stable - used in Maven ITs
  • invoker is stable
  • plugin testing harness is stable but alpha
  • plugin testing tools/component IT plugin is stable but alpha

John says: "I'm hoping to converge the tools
we're using in the core ITs with those in the maven-component-test-plugin
(used to be maven-plugin-test-plugin), and the maven-invoker-plugin, and
arrive at some single solution (a plugin) that we can use everywhere...but I
haven't even been able to come up with a unified feature list yet."

Plugin Testing Tool documentation discusses the need for a different local repository (need could be reviewed by improving local repo mechanism, so keep that functionality separate). Incorporate doc into final solution.

Test without installation (c.f. staging and unstaging of plugin - implications for concurrent execution)

Not pollute the local repository (how about using a timestamped version?)


Assembly Plugin

Runs within src/it, cleans within there
Functional tests are not included in the POM.

Dependency Plugin

Integration tests are not integrated - set up as separate test projects.

Surefire Plugin

Using the separate project with standard Maven IT practices (these are really functional tests?)

Project Info Reports

Does HTMLUnit tests on the output - manually constructs the mojo like a regular IT, uses plugin testing harness.
Quite slow, though.
Adjustments should be revised.


Component IT

Can stage/unstage plugins
Can generate JUnit wrappers for projects, but does not appear to be used
Can force a currently executing lifecycle to use a different local repository
Delegates to plugin testing tools


Can run hooks in beanshell.
Executes Maven itself, will run projects from within source tree
Tracking of exit code and exception resulting from an invocation
Maven-Home Location (location of Maven application directory)
Global Checksum policy (fail/warn, global across defined repositories)
Local Repository Location
Working Directory
Input/Output Handlers
API Logger
Global Checksum Policy (fail/warn, global across defined repositories)
Local Repository Location
Project Base Directory
POM File
POM File-Name (used in conjunction with Base Directory)
Interactive/Batch Mode (determines whether Maven prompts for input)
Offline Mode
Update-Snapshots Flag
Debug Flag (show debug-level output)
Show-Errors Flag (show exception stacktraces, but not full debug output)
Inherit-Shell-Environment Flag (inherit envars from the shell used to start the current JVM)
Reactor-Failure Behavior (fail-at-end, fail-never, etc.)
Input/Output Handlers
Build Properties (-D switches)
Build Goals can be in a config or a file
Settings Location (settings.xml file path)
Plugin has a lot of logic in one mojo, and duplicates other plugins
Caching the invoker
goals files can be interpolated with some values: values from the project pom (you must use $

Unknown macro: {pom.groupId}

notation in your goals file), In the plugin configuration you can add some properties in a interpolationsProperties element
It poms can be interpolated with some values: values from the project pom (you must use @pom.groupId@ notation in your pom file), In the plugin configuration you can add some properties in a interpolationsProperties element
The plugin support a parameter -Dinvoker.test to run only its in the directory match by the expressions used in the parameter command line is : mvn -Dinvoker.test=MWAR,simple*
includes/excludes for POM files
profiles can be specified as config or file

IT Plugin

Runs a series of POMs
Uses the embedder
Not as feature rich as the invoker
Some duplication

Plugin Management Plugin

Roughly equivalent to the component IT plugin but for general use. Could be irrelevant under local repository changes.

Test Tools

Used by component IT - does a couple of file manipulations for tests.


Duplicates a lot of utils
Encompasses a lot of needed requirements for forked execution
Used in core/surefire ITs

Verifier Plugin

Separate from verifier
Runs similar verification steps, bound to the lifecycle
Loaded from XML file
Supports regex of file, existence of file
Not overly useful - probably better to use scripts

*ITTY Plugin

Removes all integration test module output and logs.
Installs the current modules artifact with the version testing , so that the test can be 100% which artifact is being used.
Invoke child Maven processes on each of the integration test modules and capture the results.
Groovy pre/post hooks
Runs in integration test phase
Could use surefire for some other parts
Runs a set of pre-defined goals
Installs to standard local repository with version "testing"
Pollutes source directories
Select test to run (duplicates surefire configuration)
Can run tests in parallel (duplicates TestNG surefire configuration), supports timeout
Can pass offline, debug mode to tests
Supports ANSI output (should be integrated into Surefire)
Can pass arbitrary properties (via file)
Can pass arbitrary Maven flags (as arg, or via file)
Can ignore failures and skip execution
Downside: name
Forks Maven

Plugin Testing Tools

Trigger Maven builds using test projects, without incurring any sort of conflict with plugins already in use within the current (this plugin's) build.
Construct a local repository into which the test version of the plugin can be installed, allowing the main local repository to remain untouched by the tests. Integration tests can be directed to use this test-time local repository instead of the normal location.
Support tracking and analysis of results from Maven builds spawned during integration testing. As far as is reasonable, test builds should be configured in the same way as normal project builds, to make the most of test cases submitted by users along with the issues they file.
Contains an Invoker delegate

  • Note disagreement with "test suite maintenance" - integration tests != functional tests, and both should be well designed, not easily adapted from users (though easily executing users's tests and helping them construct well designed tests is a better goal)
  • Note: needs to be more specific about the goals
  • Note: Not much different between component tool and plugin tool




Plugins and libraries for testing:

  • No labels