You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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/it 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 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:

  • 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 .

  • No labels