Testing Sling-based applications
Automated testing of OSGi components and services can be challenging, as many of them depend on other services that must be present or simulated for testing.
This page describes the various approaches that we use to test Sling itself, and introduces a number of tools that can help testing OSGi and HTTP-based applications.
When possible, unit tests are obviously the fastest executing ones, and it's easy to keep them close to the code that they're testing.
We have quite a lot of those in Sling, the older use the JUnit3 TestCase base class, and later ones use JUnit4 annotations. Mixing both approaches is possible, there's no need to rewrite existing tests.
Tests that use a JCR repository
Utility classes from our commons/testing module make it easy to get a real JCR repository for testing. That's a bit slower than pure unit tests, of course, but this only adds 1-2 seconds to the execution of a test suite.
RepositoryProviderTest in that module uses this technique to get a JCR repository.
Note that our utilities do not cleanup the repository between tests, so you must be careful about test isolation, for example by using unique paths for each test.
Mock classes and services
The next step is to use mock classes and services to simulate components that are needed for testing. This makes it possible to test OSGi service classes without an OSGi framework, or classes accessing the Sling or JCR API without a running Sling instance or JCR repository.
The Development documentation page contains a section "Testing Sling-based Applications" lising all mock implementations available as part of the Apache Sling project.
In other cases we use jmock or Mockito to help create mock objects without having to write much code - such mocking libraries take care of the plumbing and allow you to write just the bits of code that matter (often with funny syntaxes). The tests of the org.apache.sling.event bundle, for example, make extensive use of such mock services.
The problem with mocks is that it can become hard to make sure you're actually testing something, and not just "mocking mocks". At a certain level of complexity, it becomes quicker and clearer to actually start an OSGi framework for automated tests.
Side note: injecting services in private fields
To inject (real or fake) services in others for testing, without having to create getters and setters just for this, you could use a reflection-based trick, as in the below example. Utilities such as the PrivateAccessor from junit-addons make that simpler.
1 2 3 4 5 6 7 8
// set resource resolver factory // in a ServletResolver object which has a private resourceResolverFactory field ServletResolver servletResolver = .... Class<?> resolverClass = servletResolver.getClass().getSuperclass(); final java.lang.reflect.Field resolverField = resolverClass.getDeclaredField("resourceResolverFactory"); resolverField.setAccessible(true); resolverField.set(servletResolver, factory);
Pax Exam allows you to easily start an OSGi framework during execution of a JUnit test suite.
We currently use it for our Sling installer integration tests for example. As parts of the installer interact directly with the OSGi framework, it felt safer to test it in a realistic situation rather than mock everything.
Such tests are obviously slower than plain unit tests and tests that use mocks. Our installer integration tests, using Pax Exam, take about a minute to execute on a 2010 macbook pro.
Sling testing tools: server-side JUnit tests
The Sling testing tools include a module that executes JUnit tests server-side, in a Sling instance. This allows integration tests to run in a realistic environment, and could also be used for self-testing production systems.
As I write this, we are not using those tools to test Sling itself, but we have a complete example of integration tests that use them to run server-side JUnit tests, including automatic setup of the test Sling instance.
HTTP-based integration tests
The highest level of integration is testing a complete Sling instance via its HTTP interface.
We use this technique to test Sling itself: the launchpad/integration-tests module defines the tests (462 of them as I write this), and the launchpad/testing module executes them, after setting up a Sling instance from scratch (which is quite easy as Sling is just a runnable jar).
A simple mechanism (described in README files in these modules) allows individual tests to be executed quickly against a previously started Sling instance, to be able to write and debug tests efficiently.
The test code could be made simpler using the fluent HTTP interfaces defined in the Sling testing tools described above, but the launchpad tests were written before that module was created, and as they're stable there's no reason to rewrite them. If you're planning on using this technique for your own applications, we recommend looking at the Sling testing tools instead of these "legacy" tests - but the basic technique is the same.
One problem with these launchpad tests is that the tests of all Sling modules are defined in a single testing module, they are not co-located with the code that they test. This could be improved by providing the tests in bundles that can be created from the same Maven modules that the code that they test.
Combining the above testing techniques has worked well for us in creating and testing Sling. Being able to test things at different levels of integration has proved an efficient way to get good test coverage without having to write too much boring test code.