Hi, I applied Andrei's patch in https://svn.apache.org/viewvc?view=revision&revision=r1742262.
Cheers, Radu On Tue, 3 May 2016 at 11:52 Andrei Dulvac <anonym...@apache.org> wrote: > 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. > >
