svn commit: r829008 - in /websites/staging/ace/trunk/content: ./ dev-doc/writing-tests.html

[bu...@apache.org]

Author: buildbot
Date: Wed Aug 15 11:58:59 2012
New Revision: 829008

Log:
Staging update by buildbot for ace

Modified:
    websites/staging/ace/trunk/content/   (props changed)
    websites/staging/ace/trunk/content/dev-doc/writing-tests.html

Propchange: websites/staging/ace/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Wed Aug 15 11:58:59 2012
@@ -1 +1 @@
-1373356
+1373358

Modified: websites/staging/ace/trunk/content/dev-doc/writing-tests.html
==============================================================================
--- websites/staging/ace/trunk/content/dev-doc/writing-tests.html (original)
+++ websites/staging/ace/trunk/content/dev-doc/writing-tests.html Wed Aug 15 11:58:59 2012
@@ -203,20 +203,20 @@
 
 <p>This snippet shows us almost all important concepts for TestNG:</p>
 <ul>
-<li>The <code>@BeforeMethod</code> annotation allows us to run a method before each individual test. In this 'setUp' method, we create a stub implementation of a <tt>LogService</tt>. <strong>Note:</strong> the <code>alwaysRun = true</code> is needed to ensure that this method is run, even though it does not belong to any test-group;</li>
-<li>The method <code>testAuthenticateFailsWithNullContext</code> is annotated with the <code>@Test</code> annotation, and its parameters tell us two more things: it belongs to a group UNIT, and there's a failure to expect in the form of an 'IllegalArgumentException'. In this method, we instantiate the class-under-test (using the stub 'LogService') and invoke a method on it;</li>
-<li>The last method (<code>testAuthenticateFailsWithoutAuthProcessors</code>) shows us how to make assertions on the results of methods. The <code>Assert</code> class of TestNG is almost equivalent to its equally named counterpart in JUnit with one difference: the failure message always comes last.</li>
+<li>The <tt>@BeforeMethod</tt> annotation allows us to run a method before each individual test. In this 'setUp' method, we create a stub implementation of a <tt>LogService</tt>. <strong>Note:</strong> the <code>alwaysRun = true</code> is needed to ensure that this method is run, even though it does not belong to any test-group;</li>
+<li>The method <tt>testAuthenticateFailsWithNullContext</tt> is annotated with the <tt>@Test</tt> annotation, and its parameters tell us two more things: it belongs to a group UNIT, and there's a failure to expect in the form of an 'IllegalArgumentException'. In this method, we instantiate the class-under-test (using the stub 'LogService') and invoke a method on it;</li>
+<li>The last method (<tt>testAuthenticateFailsWithoutAuthProcessors<tt>) shows us how to make assertions on the results of methods. The <tt>Assert</tt> class of TestNG is almost equivalent to its equally named counterpart in JUnit with one difference: the failure message always comes last.</li>
 </ul>
 <p>To run the unit tests for a project, you simply go to the root directory of the project itself, and call:</p>
 <div class="codehilite"><pre><span class="nv">$ </span>ant testng
 </pre></div>
 
 
-<p>This will run the unit tests using TestNG. The output of the tests can be found in the <code>test-output</code> directory of your project. To run the test from Eclipse, you can right click on it, and select <code>Run As -&gt; TestNG Test</code> from its context menu.</p>
+<p>This will run the unit tests using TestNG. The output of the tests can be found in the <tt>test-output</tt> directory of your project. To run the test from Eclipse, you can right click on it, and select "Run As -&gt; TestNG Test" from its context menu.</p>
 <h2 id="writing-integration-tests">Writing integration tests</h2>
 <p>In an integration test you test whether a small part of your system works as expected. For this, you need to set up an environment which resembles the situation in which the system is finally deployed. For ACE, this means that we need to set up an OSGi environment and a subset of the bundles we want to test. Fortunately, BndTools provides us with easy tooling to just do that with the use of <a href="http://pub.admc.com/howtos/junit3x/">JUnit3</a><sup id="fnref:3"><a href="#fn:3" rel="footnote">3</a></sup>.</p>
 <h3 id="integration-test-principles">Integration test principles</h3>
-<p>To write a very basic (OSGi) integration test, you need to extend your test from <code>junit.framework.TestCase</code>. To access the bundle context of your test case, you can make use of some standard OSGi utility code:</p>
+<p>To write a very basic (OSGi) integration test, you need to extend your test from <tt>junit.framework.TestCase</tt>. To access the bundle context of your test case, you can make use of some standard OSGi utility code:</p>
 <div class="codehilite"><pre><span class="kd">public</span> <span class="kd">class</span> <span class="nc">MyIntegrationTest</span> <span class="kd">extends</span> <span class="n">junit</span><span class="o">.</span><span class="na">framework</span><span class="o">.</span><span class="na">TestCase</span> <span class="o">{</span>
     <span class="kd">private</span> <span class="kd">volatile</span> <span class="n">org</span><span class="o">.</span><span class="na">osgi</span><span class="o">.</span><span class="na">framework</span><span class="o">.</span><span class="na">BundleContext</span> <span class="n">m_context</span><span class="o">;</span>