You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Andrei Dulvac <an...@apache.org> on 2016/05/03 11:52:05 UTC
CMS diff: Testing Sling-based applications
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.
Re: CMS diff: Testing Sling-based applications
Posted by Radu Cotescu <ra...@apache.org>.
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 <an...@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.
>
>