Within Sling, we have a number of different ways to implement automated testing. This is an attempt to explain these options:
| Remote HTTP Testing | Server Side JUnit | Pax Exam | |
|---|---|---|---|
| Description | Tests make various HTTP requests and make assertions upon the responses. Typically also involves creating test services and/or deploying test resources. Typically associated with "black box" testing. | JUnit tests are packaged into an OSGi bundle and deployed into a Sling instance. Test results can be viewed using a simple HTTP front end or as part of Sling Health Checks. For IDE and Maven integration, a separate test class can be created to start Sling, deploy the test bundle, and execute the tests. This is still technically "black box" testing as the tests only have access to the service APIs, but it is less "blackboxy" than pure HTTP-based testing. | JUnit tests are written and executed using the Pax Exam framework which causes an OSGi framework to be started as part of the test harness. Sling bundles are deployed into this framework and the tests are executed within the framework. |
| Sling Module | Commons Testing | Sling Test Tools | Pax Exam Utils |
| Example Project | Launchpad Integration Tests | Sling Modules Integration Tests | Sling I18N |
| Tests Run... | External Process (IDE or Maven Surefire plugin) | Within Sling JVM | Within Sling JVM |
| Usable with running instance? | Yes (by definition) | Yes (see SLING-3328) | No |