ace-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r829008 - in /websites/staging/ace/trunk/content: ./ dev-doc/writing-tests.html
Date Wed, 15 Aug 2012 11:59:00 GMT
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>
 



Mime
View raw message