You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@sling.apache.org by bd...@apache.org on 2015/09/22 11:55:34 UTC

svn commit: r1704502 - in /sling/site/trunk/content/documentation: bundles/org-apache-sling-junit-bundles.mdtext development/sling-testing-tools.mdtext

Author: bdelacretaz
Date: Tue Sep 22 09:55:32 2015
New Revision: 1704502

URL: http://svn.apache.org/viewvc?rev=1704502&view=rev
Log:
Tweak JUnit server-side docs and mark the Sling testing tools page as obsolete

Modified:
    sling/site/trunk/content/documentation/bundles/org-apache-sling-junit-bundles.mdtext
    sling/site/trunk/content/documentation/development/sling-testing-tools.mdtext

Modified: sling/site/trunk/content/documentation/bundles/org-apache-sling-junit-bundles.mdtext
URL: http://svn.apache.org/viewvc/sling/site/trunk/content/documentation/bundles/org-apache-sling-junit-bundles.mdtext?rev=1704502&r1=1704501&r2=1704502&view=diff
==============================================================================
--- sling/site/trunk/content/documentation/bundles/org-apache-sling-junit-bundles.mdtext (original)
+++ sling/site/trunk/content/documentation/bundles/org-apache-sling-junit-bundles.mdtext Tue Sep 22 09:55:32 2015
@@ -3,8 +3,13 @@ Title: JUnit server-side testing support
 This is an overview of the Sling bundles that provide support for server-side JUnit tests. 
 
 ## org.apache.sling.junit.core: server-side JUnit tests support
-The `org.apache.sling.junit.remote` bundle provides a `JUnitServlet` that runs JUnit tests found
-in bundles. 
+This bundle provides a `JUnitServlet` that runs JUnit tests found in bundles. 
+
+To make tests available to that servlet, the bundle that contains them must point to them
+with a `Sling-Test-Regexp` bundle header that defines a regular expression that matches
+the test class names, like for example:
+
+    Sling-Test-Regexp=`com.example.*ServerSideTest
 
 <div class="warning">
 Note that the JUnitServlet does not require authentication, so it would allow any client to run tests. The servlet can be disabled by configuration if needed, but in general the `/system` path should not be accessible to website visitors anyway.
@@ -14,15 +19,30 @@ Note that the JUnitServlet does not requ
 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.
 </div>
 
-To make tests available to that servlet, the bundle that contains them must point to them
-with a `Sling-Test-Regexp` bundle header that defines a regular expression that matches
-the test class names, like `Sling-Test-Regexp=`com.example.*ServerSideTest` for example.
-
 The `TeleporterRule` supplied by this bundle makes it easy to write such tests, using this
-rule they can be mixed with other tests in the source code if that's convenient. 
+rule they can be mixed with other tests in the source code if that's convenient. Here's a basic example of such a
+"teleported" test that accesses OSGi services:
+
+    public class BasicTeleporterTest {
+
+        @Rule
+        public final TeleporterRule teleporter = TeleporterRule.forClass(getClass(), "Launchpad");
+        
+        @Test
+        public void testConfigAdmin() throws IOException {
+            final String pid = "TEST_" + getClass().getName() + UUID.randomUUID();
+            
+            final ConfigurationAdmin ca = teleporter.getService(ConfigurationAdmin.class);
+            assertNotNull("Teleporter should provide a ConfigurationAdmin", ca);
+            
+            final Configuration cfg = ca.getConfiguration(pid);
+            assertNotNull("Expecting to get a Configuration", cfg);
+            assertEquals("Expecting the correct pid", pid, cfg.getPid());
+        }
+    } 
 
 Using the teleporter module described below, the `TeleporterRule` creates a temporary bundle 
-that contains the  test code along with any required classes, adds the appropriate 
+that contains the test class along with any classes required to run it, adds the appropriate 
 `Sling-Test-Regexp` header to it, installs the bundle, runs the test via the `JUnitServlet`,
 collects the results and uninstalls the bundle. This happens quickly as the temporary bundle is
 very small, and both the client-side and server-side parts of the test can be debugged easily
@@ -37,21 +57,21 @@ package.
 To try the JUnitServlet interactively, you can install the 
 [org.apache.sling.testing.samples.sampletests](http://svn.apache.org/repos/asf/sling/trunk/testing/samples/sample-tests) 
 bundle, or any other bundle that contains tests and a `Sling-Test-Regexp` bundle header that points to them, as
-described above. Or use the TeleporterRule`and set a breakpoint in the tests execution, when the test bundle ins
-installed and will be listed by the test servlet.
+described above. Or use the `TeleporterRule`and set a breakpoint in the tests execution, when the test bundle in
+installed and listed by the test servlet.
 
-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.
+To list the available tests, open `/system/sling/junit/` in your browser. 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
+`/system/sling/junit/org.apache.sling.junit.remote.html`
  
  The JUnitServlet provides various output formats, including in particular JSON, see 
- http://localhost:8080/system/sling/junit/.json for example.
+ `/system/sling/junit/.json` for example.
 
 ## org.apache.sling.junit.teleporter: client-side TeleporterRule support
-This module mostly provides the `ClientSideTeleporter` which the `TeleporterRule` uses to teleport the tests
-to the server side. It is only used on the client as a dependency when running the tests.
+This module provides the `ClientSideTeleporter` which the `TeleporterRule` uses to teleport the tests
+to the server side. It is not a bundle, as it's used on the client only, as a dependency when running the tests.
 
 A `TeleporterRule.Customizer` is used to setup the `ClientSideTeleporter`. That customizer is instantiated dynamically
 based on a String passed to the `TeleporterRule` creation code.
@@ -61,9 +81,8 @@ As an example from our `launchpad/integr
     TeleporterRule.forClass(getClass(), "Launchpad:author");
     
 Causes the `TeleporterRule` to use the `org.apache.sling.junit.teleporter.customizers.LaunchpadCustomizer` class
-to setup the `ClientSideTeleporter`, and passes the "author" string to it as an option. This can be used to select 
-which server to run the tests on, in this case the customizer could look for a server that runs with the "author" 
-run mode.
+to setup the `ClientSideTeleporter`, and passes the "author" string to it as an option. Although our current `LaunchpadCustomizer`
+does not use this options string, it is meant to select a specific server (of family of servers) to run the tests on.
 
 The options string can also use a full class name instead of the `Launchpad` short form used here, if needed. The part
 of that string that follows the first colon is passed to the customizer as is.
@@ -73,10 +92,12 @@ classes which are used only on the clien
 
 ## org.apache.sling.junit.healthcheck: run JUnit tests as Sling Health Checks
 This bundle allows JUnit tests to run as [Sling Health Checks](/documentation/bundles/sling-health-check-tool.html),
-which can be useful when defining smoke tests for example, allowing them to be used both at build time and run time. 
+which can be useful when defining smoke tests for example, allowing them to be used both at build time and run time.
+
+See the `JUnitHealthCheck` class for details. 
 
 ## org.apache.sling.junit.scriptable: scriptable server-side tests
-This bundle allows Sling scripts to be executed from the `JUnitServlet`, as follows:
+This bundle allows Sling scripts to be executed from the `JUnitServlet` as JUnit tests, as follows:
 
 * 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.

Modified: sling/site/trunk/content/documentation/development/sling-testing-tools.mdtext
URL: http://svn.apache.org/viewvc/sling/site/trunk/content/documentation/development/sling-testing-tools.mdtext?rev=1704502&r1=1704501&r2=1704502&view=diff
==============================================================================
--- sling/site/trunk/content/documentation/development/sling-testing-tools.mdtext (original)
+++ sling/site/trunk/content/documentation/development/sling-testing-tools.mdtext Tue Sep 22 09:55:32 2015
@@ -1,5 +1,10 @@
 Title: Sling Testing Tools
 
+<div class="warning">
+While this information is still valid, we recommend using the tools and techniques described
+in the newer [Junit Server-Side Tests Support]({{ refs.org-apache-sling-junit-bundles.path }}) page instead. 
+</div>
+
 Sling provides a number of testing tools to support the following use cases:
 
 * Run JUnit tests contributed by OSGi bundles in an OSGi system. This does not require Sling and should work in other OSGi  environments.