Page History

...

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/maintest/itjava 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:

...

• Tests using the HTTP API of Sling, based on the Sling Testing Clients bundle 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 .

This is also tracked with