brekke 02/01/03 21:24:15 Modified: xdocs application-testing.xml Added: xdocs/testing standalone.xml Log: Reformatted the application-testing.xml file to be spaced like other xml docs in the tdk. Also added the first link to some content. Created a testing directory to hold the content of the testing tips. Added the content showing two examples of how to start turbine in standalone mode for testing. Revision Changes Path 1.2 +100 -83 jakarta-turbine-tdk/xdocs/application-testing.xml Index: application-testing.xml =================================================================== RCS file: /home/cvs/jakarta-turbine-tdk/xdocs/application-testing.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- application-testing.xml 3 Jan 2002 19:14:25 -0000 1.1 +++ application-testing.xml 4 Jan 2002 05:24:15 -0000 1.2 @@ -1,86 +1,103 @@ <?xml version="1.0"?> - <document> - <properties> - <title>Application Testing</title> - <author email="[EMAIL PROTECTED]">Jeffrey D. Brekke</author> - </properties> - - <body> - - <section name="Application Testing"> - <p> - These samples are for testing your code which uses the Turbine framework. - We take care not to involve testing Turbine itself, but more how to - exercise your application code. If you are looking for unit tests of - the Turbine source code itself, this is the incorrect document. These - are testing techniques for applications implemented with Turbine. - The samples and techniques use various frameworks such as JUnit, - HttpUnit, and Cactus. A Reference section is provided with links - to more information about the frameworks and techniques used in the - sample code. - </p><p> - This document is very much a work in progress as the sample tests are - directly taken from our code we are currently developing. Hopefully - this document will serve not only as a reference for starting to test - your Turbine based applications, but a place to collect and document - testing techniques the Turbine application developer may use. - </p><p> - Extreme Programming breaks testing into two parts, Developer Tests, and - Customer Tests. This document contains tips for both kinds of tests. - Each one is slightly different so some explanation will be helpful. - This is a very short, high level description of the test types. More - detailed information may be found in the reference section. - </p><p> - Developer Tests are unit tests written by the developers - as the production code is written. Another practice of Extreme - Programming is Test-First Coding, where the test is written, fails, then - the code is written to make it pass. Developer Tests can be thought of as - white-box testing. Inspection of the state of the code in the unit under - test is important in this type of testing. All Developer Tests must be - running at 100%, no failures, at all times. JUnit is the framework - used for these tests described here. - </p><p> - Customer Tests are more like black-box tests. They test that the feature - ( user story in XP-speak ) is functioning properly. This type of test - could also be thought of as end-to-end testing or system testing. - If your application has a feature to generate a pdf report, a Customer - Test may be: <i>Given inputs x and y, the pdf should look like z</i>. We've - generally used HttpUnit to simulate the user-agent accessing our web - applications and verify its output. - </p> - </section> - - <section name="Developer Testing"> - <UL> - <LI> - <b>Tip:</b> Start Turbine standalone without a servlet container to test torque objects, global pull tools, and other services. - </LI> - <LI> - <b>Tip:</b> Use mock objects for RunData and Context to test actions. - </LI> - <LI> - <b>Tip:</b> Use simple anonymous inner classes to mock your torque object for testing. - </LI> - </UL> - - </section> - - <section name="Customer Testing"> - <UL> - <LI> - <b>Sample:</b> HttpUnit test case of a turbine application. - </LI> - </UL> - </section> - - <section name="Reference"> - <UL> - <li><a href="http://jakarta.apache.org/cactus";>Cactus</a></li> - <li><a href="http://httpunit.sourceforge.net";>HttpUnit</a></li> - <li><a href="http://www.junit.org";>JUnit</a></li> - <li><a href="http://www.mockobjects.com";>Mock Objects</a></li> - </UL> - </section> - </body> +<document> + + <properties> + <title>Application Testing</title> + <author email="[EMAIL PROTECTED]">Jeffrey D. Brekke</author> + </properties> + +<body> + +<section name="Application Testing"> +<p> +These samples are for testing your code which uses the Turbine +framework. We take care not to involve testing Turbine itself, but more +how to exercise your application code. If you are looking for unit +tests of the Turbine source code itself, this is the incorrect +document. These are testing techniques for applications implemented +with Turbine. The samples and techniques use various frameworks such as +JUnit, HttpUnit, and Cactus. A Reference section is provided with +links to more information about the frameworks and techniques used in +the sample code. +</p> + +<p> +This document is very much a work in progress as the sample tests are +directly taken from our code we are currently developing. Hopefully +this document will serve not only as a reference for starting to test +your Turbine based applications, but a place to collect and document +testing techniques the Turbine application developer may use. +</p> + +<p> +Extreme Programming breaks testing into two parts, Developer Tests, and +Customer Tests. This document contains tips for both kinds of tests. +Each one is slightly different so some explanation will be helpful. +This is a very short, high level description of the test types. More +detailed information may be found in the reference section. +</p> + +<p> +Developer Tests are unit tests written by the developers as the +production code is written. Another practice of Extreme Programming is +Test-First Coding, where the test is written, fails, then the code is +written to make it pass. Developer Tests can be thought of as +white-box testing. Inspection of the state of the code in the unit +under test is important in this type of testing. All Developer Tests +must be running at 100%, no failures, at all times. JUnit is the +framework used for these tests described here. +</p> + +<p> +Customer Tests are more like black-box tests. They test that the +feature ( user story in XP-speak ) is functioning properly. This type +of test could also be thought of as end-to-end testing or system +testing. If your application has a feature to generate a pdf report, a +Customer Test may be: <i>Given inputs x and y, the pdf should look like +z</i>. We've generally used HttpUnit to simulate the user-agent +accessing our web applications and verify its output. +</p> +</section> + +<section name="Developer Testing"> +<UL> + +<LI> +<a href="testing/standalone.html"> +<b>Tip:</b> Start Turbine in <i>standalone mode</i> +</a> +</LI> + +<LI> +<b>Tip:</b> Use mock objects for RunData and Context +</LI> + +<LI> +<b>Tip:</b> Simple anonymous inner classes to mock torque objects +</LI> + +</UL> +</section> + +<section name="Customer Testing"> +<UL> + +<LI> +<b>Sample:</b> HttpUnit test case of a turbine application +</LI> + +</UL> +</section> + +<section name="Reference"> +<UL> +<li><a href="http://jakarta.apache.org/cactus";>Cactus</a></li> +<li><a href="http://httpunit.sourceforge.net";>HttpUnit</a></li> +<li><a href="http://www.junit.org";>JUnit</a></li> +<li><a href="http://www.mockobjects.com";>Mock Objects</a></li> +</UL> +</section> + +</body> </document> 1.1 jakarta-turbine-tdk/xdocs/testing/standalone.xml Index: standalone.xml =================================================================== <?xml version="1.0"?> <document> <properties> <title>Start Turbine in standalone mode</title> <author email="[EMAIL PROTECTED]">Jeffrey D. Brekke</author> </properties> <body> <section name="Start Turbine in standalone mode"> <p> In order to test certain code that is using some of Turbine's services and singletons, it may be required to have Turbine running. Turbine started without a servlet container is considered running in <i>standalone mode</i>. The javadocs for TurbineConfig have more information but below is how to start Turbine in <i>standalone mode</i>. </p> <source><![CDATA[ TurbineConfig config = null; config = new TurbineConfig("../", "/conf/test.TurbineResources.properties"); config.init(); ]]></source> <p> So our test case needs to start Turbine, run our tests, and stop Turbine. Stopping Turbine is easy since the objects are destroyed when the test case terminates. There are two ways to write test cases with Turbine running standalone. The first method is to define a base class that starts up Turbine in a static initializer. Then all your test cases that need Turbine running should descend this base test case. </p> <source><![CDATA[ package myapp.test; import junit.framework.TestCase; import org.apache.turbine.util.TurbineConfig; import org.apache.turbine.util.StringUtils; /** Base test case used to start Turbine in standalone mode. */ public class TurbineStandaloneTestCase extends TestCase { /* Configuration object to run Turbine outside a servlet container ( uses turbine.properties ) */ private static TurbineConfig config = null; /** Sets up TurbineConfig using the system property: <pre>turbine.properties</pre> */ static { try { config = new TurbineConfig( "..", System.getProperties().getProperty( "turbine.properties", "/conf/TurbineResources.properties" ) ); config.init(); } catch (Exception e) { fail(StringUtils.stackTrace(e)); } } public TurbineStandaloneTestCase( String name ) { super( name ); } } ]]></source> <p> The base class test case method of starting Turbine has one drawback. If you have many test cases that descend TurbineStandaloneTestCase, each one will start Turbine, run some tests, and stop Turbine. This may slow down the testing process, especially when the unit tests are automated. The second method uses the TestSetup decorator provided by JUnit to start Turbine for a set of test cases. In this case we create an AllTests class which runs the test cases for us. </p> <source><![CDATA[ package myapp.test; import junit.framework.TestCase; import junit.framework.TestSuite; import junit.extensions.TestSetup; import junit.framework.Test; import org.apache.turbine.util.TurbineConfig; import org.apache.turbine.util.StringUtils; /** Runs all the unit tests for the current package. */ public class AllTests extends TestCase { public AllTests(String name) { super(name); } public static Test suite() { /* These are tests that need Turbine running */ TestSuite tsuite = new TestSuite(); tsuite.addTest(test1Test.suite()); tsuite.addTest(test2Test.suite()); tsuite.addTest(test3Test.suite()); TestSetup wrapper= new TestSetup(tsuite) { private TurbineConfig config = null; public void setUp() { try { config = new TurbineConfig("../", System.getProperties().getProperty( "turbine.properties", "/conf/test.TurbineResources.properties") ); config.init(); } catch (Exception e) { fail( StringUtils.stackTrace(e) ); } } }; TestSuite realSuite = new TestSuite(); /* These are tests that don't need Turbine started */ realSuite.addTest(test4Test.suite()); realSuite.addTest(test5Test.suite()); realSuite.addTest(wrapper); return realSuite; } } ]]></source> <p> The AllTests class creates a test suite containing the tests that require Turbine to be started. Then a TestSetup wrapper is created around that suite of tests. A return suite is built with test 4 and 5 that do not require Turbine running. The wrapper suite containing the decorator and tests 1, 2, and 3 are then added to the return suite. The order the test cases will run is: 4, 5, 1, 2, 3. This now ensures that Turbine is started once for tests 1, 2 and 3. The drawback to this method is you cannot run one test case alone, you must always run all the tests. The first method, since Turbine is started for each case, you can run each test individually. </p> </section> </body> </document>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
