Clone URL (Committers only):
https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://sling.apache.org/documentation%2Ftutorials-how-tos%2Ftesting-sling-based-applications.mdtext
Andrei Dulvac
Index:
trunk/content/documentation/tutorials-how-tos/testing-sling-based-applications.mdtext
===================================================================
---
trunk/content/documentation/tutorials-how-tos/testing-sling-based-applications.mdtext
(revision 1711830)
+++
trunk/content/documentation/tutorials-how-tos/testing-sling-based-applications.mdtext
(working copy)
@@ -60,17 +60,54 @@
running JUnit tests on an live Sling instance, as part of the normal
integration testing cycle.
## HTTP-based integration tests
+The [Sling HTTP Testing
Rules](https://svn.apache.org/repos/asf/sling/trunk/testing/junit/rules) allow
writing integration tests easily. They are primarily meant to be used for tests
that use http against
+a Sling instance and make use of the
[org.apache.sling.testing.clients](https://svn.apache.org/repos/asf/sling/trunk/testing/http/clients)
which offer a simple, immutable and extendable way of working
+with specialized testing clients.
-The highest level of integration is testing a complete Sling instance via its
HTTP interface.
+The JUnit rules incorporate boiler-plate logic that is shared in tests and
take the modern approach of using rules rather than
+inheritance. The `SlingRule` (for methods) or `SlingClassRule` (for test
classes) are base rules, chaining other rules like `TestTimeoutRule`,
+`TestDescriptionRule`, `FilterRule`. The `SlingInstanceRule` extends that and
starts a Sling instance if needed and also allows
+instantiating a `SlingClient` pointing to the instance and automatically
configure the base url, credentials, etc.
+
-We use this technique to test Sling itself: the
[launchpad/integration-tests](https://svn.apache.org/repos/asf/sling/trunk/launchpad/integration-tests)
module defines the tests (462 of them as I write this), and the
[launchpad/testing](https://svn.apache.org/repos/asf/sling/trunk/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 name="starting"></a> Starting an Integration Test
+Starting an integration is very simple out of the box, but is very extendable,
both by combining or configuring the junit rules and by
+using the versatile `SlingClient` (which can be extended or adapted by calling
`adaptTo(MyClient.class)` without losing the client
+configuration)
-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
[README](https://svn.apache.org/repos/asf/sling/trunk/testing/junit/rules/README.md)
provides more detail, as do [the
tests](https://svn.apache.org/repos/asf/sling/trunk/testing/junit/rules/src/test/java).
+The [Sling HTTP Testing
Clients](https://svn.apache.org/repos/asf/sling/trunk/testing/http/clients)
provide simple explanations, and unit tests.
-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.
+#### Maven Dependency
+ #!xml
+ <dependency>
+ <groupId>org.apache.sling</groupId>
+ <artifactId>org.apache.sling.testing.rules</artifactId>
+ <version>0.1.0-SNAPSHOT</version>
+ </dependency>
-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.
+#### Simple Example using SlingInstanceRule
+
+ #!java
+ public class MySimpleIT {
+
+ @ClassRule
+ public static SlingInstanceRule instanceRule = new SlingInstanceRule();
+
+ @Rule
+ public SlingRule methodRule = new SlingRule(); // will configure test
timeout, description, etc.
+
+ @Test
+ public void testCreateNode() {
+ SlingClient client = instanceRule.getAdminClient();
+ client.createNode("/content/myNode", "nt:unstructured");
+ Assert.assertTrue("Node should be there",
client.exists("/content/myNode"));
+
//client.adaptTo(OsgiConsoleClient.class).editConfigurationWithWait(10,
"MYPID", null, myMap);
+ }
+ }
+
+
## Summary
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.
