Subject: Exported From Confluence
Content-Type: text/html; charset=UTF-8
Currently, Maven only supports unit testing out of the box. What we want=
is something flexible enough to work without having to make test definitio=
Types of Tests
- run before package
- want 100% success before moving on generally
- require the artifact, so run after package but before install.
- generally want 100% before moving on.
- May use junit or other plugin like cactus, including deploying to a =
- also called functional or regression tests.
- not run every time, probably a report and/or part of a profile.
- run after install, before deploy
- Regression tests (acceptance tests from previous milestones) should =
be at 100%
- acceptance (also called functional) tests only need to get to 100% a=
t release time.
- performance/stress tests - another form of acceptance test.
- plugin integration tests (c.f. eclipse plugin)
- report integration tests (see Vincent S's work - htmlunit)
- cactus plugin
- geronimo itest plugin
- need to be able to compile additional sources, have own dependencies=
(basically reapply the whole test lifecycle again - given that this also m=
atches the main one, perhaps that can be reusable/forked)
- we should have a setup and teardown phase around the actual test goa=
- may want to reapply test stuff on other test sets (eg junit report, =
separate project is ideal, but
- a bit unnatural, more strung out
- doesn't fit IDE well
- you can still use it if you support in project tests, so better to d=
While a separate project might be something we recommend, I think we nee=
d to support them within the same project.
Plugin integration test=
This means running a separate instance of Maven to do it effectively, so=
should always be separate projects utilising the built archive without req=
uiring it be installed (bound to the integration test phase).
How can we ensure the integration test of the subproject is run =
before installation of the parent?
Perhaps it is better to have a plugin integration testing pl=
ugin that actually runs from the parent and execs maven on the subproject.<=
Report integration test=
This should be done in an identical fashion to a plugin integration test=
, but using htmlunit to test the output. This means having junit test cases=
Junit Integration Tests<=
We have an issue here in that we would have to recofigure the whole plug=
in, essentially needing to know its information. Can we preconfigure it, li=
ke we do with the forked lifecycles? Or is it best to just wire this one in=
by default to the integration testing parts of the lifecycle and use a dif=
ferent mojo (surefire:itest, compiler:itestCompile)?
Junit Acceptance Tests
These would be set up in the same way as the junit integration tests exc=
ept for the time at which they are run. The main difference may be that the=
default configuration would be to change the required acceptance to pass. =
It may be better to have a different plugin for these in general, but the d=
efault would also be surefire like above.
pplying junit report/clover to other test sets