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:
- dependencies are defined in the Sling Starter, for instance
- the Sling Launchpad Testing module would at runtime look for
test-jardependencies defined for each of the bundle
- When finding such a dependency, for instance
org.apache.sling:org.apache.sling.servlets.get:2.0.10:test-jarit would add it to the list of tests to run
Tests to consider relocating
The concept of an IT has multiple meanings in the Sling world, and we have at least:
- Tests using the HTTP API of Sling, based on the Sling Testing Clients or the older Sling Testing Tools
- Teleporter tests
- Pax-Exam tests
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 .