Draft
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

Overview

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.

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.
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.

...

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.

...

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.

Requirements

	CIT	ITP	VER	STY
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?)

Usages

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.

Techs

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

Invoker

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.

Verifier

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

Proposals

Resources

Discussions:

Plugins and libraries for testing:

Review of Plugin Testing Strategies