[CONF] Apache Sling Website > Sling Testing Tools

confluence Wed, 23 Mar 2011 06:03:25 -0700

Sling Testing Tools

Page edited by Bertrand Delacretaz

Changes (6)

Full Content

Sling provides a number of testing tools that enable the following use cases:

Run JUnit tests contributed by OSGi bundles in an OSGi system. This does not require Sling, but works in Sling of course.
Run scriptable tests in a Sling instance, using any supported scripting language.
Run integration tests via HTTP against a Sling instance that is started during the Maven build cycle.

This pages describes those tools, and points to the bundles that implement them.

The testing/samples/integration-tests module demonstrates these tools, and is also meant as a sample project to show how to run integration tests for Sling-based applications.

The main Sling integration tests at launchpad/integration-tests were created before this testing framework, and do not (as of March 2011) use it. The new testing tools are simpler to use, but the "old" tests (all 400 of them as I write this) fulfill their validation role for testing Sling itself, there's no real need to modify them to use the new tools.

Server-side JUnit tests contributed by bundles

The services provided by the org.apache.sling.junit.core bundle allow bundles to register JUnit tests, which are executed server-side by the JUnitServlet which is registered by default at /system/sling/junit. This bundle is not dependent on Sling, it should work in other OSGi contexts.

JUnit servlet security
Note that the JUnitServlet does not require authentication. The servlet can be disabled by configuration if needed, but in general the /system path should not be accessible to website visitors anyway.

SlingJUnitServlet
For tighter integration with Sling, the alternate SlingJUnitServlet is registered with the sling/junit/testing resource type and .junit selector, if the bundle is running in a Sling system. Using this servlet instead of the plain JUnitServlet also allows Sling authentication to be used for running the tests, and the standard Sling request processing is used, including servlet filters for example.

To try the JUnitServlet interactively, install the org.apache.sling.testing.samples.sampletests bundle.

This bundle contains a number of test classes, which are registered with the org.apache.sling.junit.core services by way of the Sling-Test-Regexp=.*Test bundle header, defined in the bundle's pom.xml. The JUnit core services use this regular _expression_ to select which classes of the test bundle should be executed as JUnit tests.

To list the available tests, open http://localhost:8080/system/sling/junit/ . The servlet shows available tests, and allows you to execute them via a POST request.

Adding a path allows you to select a specific subset of tests, as in http://localhost:8080/system/sling/junit/org.apache.sling.junit.remote.html - the example integration tests described below use this to selectively execute server-side tests. The JUnitServlet provides various output formats, including in particular JSON, see http://localhost:8080/system/sling/junit/.json for example.

Here's an example executing a few tests using curl:

Running tests with curl

$ curl -X POST http://localhost:8080/system/sling/junit/org.apache.sling.testing.samples.sampletests.JUnit.json
[{
    "INFO_TYPE": "test",
    "description": "testPasses(org.apache.sling.testing.samples.sampletests.JUnit3Test)"
  },{
    "INFO_TYPE": "test",
    "description": "testPasses(org.apache.sling.testing.samples.sampletests.JUnit4Test)"
  },{
    "INFO_TYPE": "test",
    "description": "testRequiresBefore(org.apache.sling.testing.samples.sampletests.JUnit4Test)"
  }
]


And another example with a test that fails:
Failing tests with curl

$ curl -X POST http://localhost:8080/system/sling/junit/org.apache.sling.testing.samples.failingtests.JUnit4FailingTest.json
[continuous integration|SLINGxSITE:Project Information]



Scriptable server-side tests
If the org.apache.sling.junit.scriptable bundle is active in a Sling system, (in addition to the org.apache.sling.junit.core bundle), scriptable tests can be executed by the JUnitServlet according to the following rules:


	A node that has the sling:Test mixin is a scriptable test node.
	For security reasons, scriptable test nodes are only executed as tests if they are found under /libs or /apps, or more precisely under a path that's part of Sling's ResourceResolver search path.
	To execute a test, the scriptable tests provider requests the test node with a .test.txt selector and extension, and expects the output to contain only the string TEST_PASSED. Empty lines and comment lines starting with a hash sign (#) are ignored in the output.



The ScriptableTestsTest class, from the integration test samples module described below, sets up such a test node and its accompanying script, and calls the JUnitServlet to execute the test. It can be used as a detailed example of how this works.

Integration tests example
The testing/samples/integration-tests module runs some simple integration tests against a Sling Launchpad instance that's setup from scratch before running the tests.

This module's pom and Java code can be used as examples to setup your own integration testing module. Besides serving as examples, some of the tests in this module are used to validate the testing tools. They run as part of the full Sling continuous integration build.

The sample uses the testing/tools to make the test code simpler. See the OsgiConsoleTest class for an example of a test that's very readable and requires no test setup or boilerplate code.

The following steps are executed in the integration-test phase of this module's Maven  build:

	A random port number for the Sling server is selected by the Maven build helper plugin, unless explicitely set (see pom.xml for such options).
	Additional bundles, defined in the module's pom, are downloaded from the Maven repository in the target/sling/additional-bundles folder.
	The first test that inherits from the SlingTestBase class causes the Sling runnable jar (defined in module's pom) to be started.
	
		The SlingTestBase class waits for the Sling server to be ready, based on URLs and expected responses defined in the pom.
		The SlingTestBase class installs and starts the bundles found in the target/sling/additional-bundles folder.
	
	
	The test can now either test Sling directly via its http interface, or use the JUnitServlet to execute server-side tests contributed by bundles or scripts, as described above.
	The Sling runnable jar is stopped when the test VM exits.
	The test results are reported via the usual Maven mechanisms.



If -DkeepJarRunning is used on the Maven command line, the Sling runnable jar does not exit, to allow for running individual tests against this instance, for example when debugging the tests or the server code. See the pom for details.

Remote test execution
TODO

Change Notification Preferences

View Online | View Changes | Add Comment

[CONF] Apache Sling Website > Sling Testing Tools

Sling Testing Tools

Page edited by Bertrand Delacretaz

Changes (6)

Full Content

Server-side JUnit tests contributed by bundles

Scriptable server-side tests

Integration tests example

Remote test execution

Reply via email to