Currently we have integration tests (ITs) defined in the
org.apache.sling.launchpad.tests module, and also some ITs split amongst various modules - Sightly Testing and Models ITs are some examples.
Having tests close to the code is very good as the feedback cycle is very short and we don't risk missing issues until after a release is done. However, having tests grouped in a single module is effective as well - we're using it to test Sling on multiple JVMs quite easily. The question now is whether we can have the best of both worlds - tests living next to the code but also executed centrally in a single global IT job.
The proposal would see the tests moved to each bundle in the
src/test/java module and executed for each module on
mvn verify. These tests would then also be collected and launched in the
org.apache.sling.launchpad.testing module. The
test-jar dependency would only package integration tests, as unit tests will not be executed as part of the global Sling IT module.
The dependencies would ideally be implicit:
test-jardependencies defined for each of the bundle
org.apache.sling:org.apache.sling.servlets.get:2.0.10:test-jarit would add it to the list of tests to run
The concept of an IT has multiple meanings in the Sling world, and we have at least:
In my opinion the first two should definitely be included and executed in the consolidated IT module. I am not sure about the third one, since technically those tests do not have to run against a defined Sling launchpad. See for instance the commons.log pax-exam ITs .
This is also tracked with