Rationale

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.

Proposal

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 org.apache.sling:org.apache.sling.servlets.get:2.0.10
  • the Sling Launchpad Testing module would at runtime look for test-jar dependencies 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-jar it 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:

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 SLING-7936 - Getting issue details... STATUS

  • No labels