svn commit: r507779 - /incubator/tuscany/java/sca/runtime/itest/plugin/src/site/apt/usage.apt

[jb...@apache.org]

Author: jboynes
Date: Wed Feb 14 18:13:46 2007
New Revision: 507779

URL: http://svn.apache.org/viewvc?view=rev&rev=507779
Log:
more itest plugin documentation

Modified:
    incubator/tuscany/java/sca/runtime/itest/plugin/src/site/apt/usage.apt

Modified: incubator/tuscany/java/sca/runtime/itest/plugin/src/site/apt/usage.apt
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/runtime/itest/plugin/src/site/apt/usage.apt?view=diff&rev=507779&r1=507778&r2=507779
==============================================================================
--- incubator/tuscany/java/sca/runtime/itest/plugin/src/site/apt/usage.apt (original)
+++ incubator/tuscany/java/sca/runtime/itest/plugin/src/site/apt/usage.apt Wed Feb 14 18:13:46 2007
@@ -38,13 +38,104 @@
   For example, to test a component that implemented the <<<MyService>>> interface you could write:
 
 +---+
-    public class ServiceTestComponent extends TestCase {
+public class ServiceTestComponent extends TestCase {
 
-        @Reference
-        public MyService service;
+    @Reference
+    public MyService service;
 
-        public void testSomething() {
-            assertEquals(result, service.doSomething);
-        }
+    public void testSomething() {
+        assertEquals(result, service.doSomething);
     }
+}
 +---+
+
+  This TestCase is used as a component within a SCA composite that defines the test suite
+  as described in the next section. This separates TestCase's for normal unit tests from
+  those that are integration tests.
+
+  If any methods have an SCA <<<...@Init>>> or <<<...@Destroy>>> annotation they will be called
+  before and after executing tests; if no methods are annotated in this way the normal
+  JUnit <<<setUp>>> and <<<tearDown>>> methods will be called.
+
+  If the component's scope is <<<STATELESS>>> (the default), then a new instance of the
+  test component will used to run each test; if the component's scope is <<<COMPOSITE>>>
+  then a single instance will be used to run all tests. The scope can be set with the
+  standard SCA <<<...@Scope>>> annotation.
+
+* Defining an SCA Test Suite
+
+  The Test Suite for your integration tests is defined by an SCA composite file that contains
+  the test components written above wired to the production components for the application.
+  The test components must use an implementation type of <<< <tuscany:junit> >>>.
+  
+  A simple way to achieve this is to use a SCDL <include> element to include the content of
+  production composite in the test harness; this gives the test components access to all of
+  the components and references in the production composite.
+
+  For example, the following SCDL configures the <<<ServiceTestComponent>>> above
+  to test the <<<MyServiceComponent>>> in the production composite <<<ProductionComposite>>>:
+
++---+
+<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
+           xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0"
+           name="PropertyTestHarnessComposite">
+
+    <include name="ProductionComposite" scdlResource="META-INF/sca/default.scdl"/>
+
+    <component name="testMyService">
+        <tuscany:junit class="ServiceTestComponent"/>
+        <reference name="service">MyServiceImpl</reference>
+    </component>
+</composite>
++---+
+
+  Alternatively, the production composite can be tested as a black box by using it to
+  implement a component and wiring test components to it. This allows the externally
+  visible services to be tested without knowledge of the internals of the composite.
+
+  For example, the following SCDL tests the <<<ProductionComposite>>> in this way:
+
++---+
+<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
+           xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0"
+           name="PropertyTestHarnessComposite">
+
+    <component name="ProductionComponent">
+        <implementation.composite name="ProductionComposite"
+                                  scdlResource="META-INF/sca/default.scdl"/>
+    </component>
+
+    <component name="testMyService">
+        <tuscany:junit class="ServiceTestComponent"/>
+        <reference name="service">ProductionComponent</reference>
+    </component>
+</composite>
++---+
+
+  The location of this test composite definition can be specified using the <<<testScdl>>>
+  plugin configuration property; the default location is <<<${project.build.testOutputDirectory}/itest.scdl>>>
+  which allows the <<<itest.scdl>>> source file to be placed in the test resources (<<<src/test/resources>>>).
+
+* Test Result Output
+
+  The test results are output using Surefire's reporting framework for integration with other test reports.
+  XML and test results are stored in the normal test output directory (<<<target/surefire-reports>>>) with
+  a summary displayed on the console:
+
++---+
+[INFO] [tuscany-itest:test {execution: default}]
+[INFO] Starting Tuscany...
+[INFO] Deploying test SCDL from .../target/test-classes/itest.scdl
+[INFO] Executing tests...
+
+-------------------------------------------------------
+ T E S T S
+-------------------------------------------------------
+Running testMyService
+Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
+
+Results :
+Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
+
+[INFO] Stopping Tuscany...
++---+
\ No newline at end of file



---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-commits-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-commits-help@ws.apache.org