vmassol 01/08/04 01:19:40
Modified: cactus/docs/framework/xdocs features.xml
Log:
updated, added better explanations and added general design features
Revision Changes Path
1.8 +106 -46 jakarta-commons/cactus/docs/framework/xdocs/features.xml
Index: features.xml
===================================================================
RCS file: /home/cvs/jakarta-commons/cactus/docs/framework/xdocs/features.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- features.xml 2001/08/03 22:29:24 1.7
+++ features.xml 2001/08/04 08:19:40 1.8
@@ -12,17 +12,51 @@
<body>
- <s1 title="Cactus feature list">
+ <s1 title="General design features">
+
+ <ul>
+ <li>
+ Cactus gives you a very good confidence that your code is going
+ to run fine on the server it will be deployed to (thanks to Cactus
+ in-container approach that executes the test <em>inside</em> the
+ container),
+ </li>
+ <li>
+ Cactus let you test container interactions. This is essential
+ in a world where containers are providing more and more
+ features for their components every day,
+ </li>
+ <li>
+ Cactus let you test and automate the deployment process to your
+ server (using prebuilt powerful custom Ant task),
+ </li>
+ <li>
+ Cactus does not mandate any change to your classes to test, although
+ it helps think about writing better code and do some refactoring,
+ </li>
+ <li>
+ Cactus provides a good middle ground in term of test graininess :
+ too fine-grained tests are hard to write (like mock objects tests
+ that completely simulates the domain objects and focus exclusively
+ on unit testing your logic code) and need complementary tests. Too
+ coarse-grained tests (like functional tests) are not enough to
+ easily uncover bugs and work in a iterative development process
+ where tests are run very often to ensure everything is working
+ </li>
+ </ul>
+
+ </s1>
+
+ <s1 title="Detailed feature list">
<p><br/></p>
<ul>
<li>
Integrates seamlessly with the JUnit testing framework.
<ul>
<li>
- Your testing class just has to extend
- <code>org.apache.commons.cactus.ServletTestCase</code> or
- <code>org.apache.commons.cactus.JspTestCase</code> (which
- themselves extends <code>junit.framework.TestCase</code>)
+ Your testing class just has to extend one of Cactus
+ <code>org.apache.commons.cactus.<XXX>TestCase</code> classes
+ (which themselves extends <code>junit.framework.TestCase</code>)
instead of extending <code>junit.framework.TestCase</code>
directly.
</li>
@@ -33,21 +67,50 @@
</ul>
</li>
<li>
- Execute your test methods in a servlet/JSP environment, i.e. you have
- access to the following implicit objects : <code>request</code> ( of
- type <code>HttpServletRequest</code>), <code>response</code> (of type
- <code>HttpServletResponse</code>), <code>session</code> (of type
- <code>HttpSession</code>), <code>config</code> (of type
- <code>ServletConfig</code>). Moreover you can also have access to 2
- additional JSP implicit objects if you need them in your test class :
- <code>pageContext</code> (of type <code>PageContext</code>) and
- <code>out</code> (of type <code>JspWriter</code>).
+ Provides different <code><XXX>TestCase</code> classes which
+ have class variables that are container objects (called implicit
+ objects thereafter). You will be able to use
+ these objects in you test code to call your methods to unit test.
+ <ul>
+ <li>
+ <code>ServletTestCase</code> : provides all Servlet API objects
+ <ul>
+ <li>
+ <code>request</code> (of type
+ <code>HttpServletRequest</code>),
+ </li>
+ <li>
+ <code>response</code> (of type
+ <code>HttpServletResponse</code>),
+ </li>
+ <li>
+ <code>session</code> (of type
+ <code>HttpSession</code>),
+ </li>
+ <li>
+ <code>config</code> (of type
+ <code>ServletConfig</code>).
+ </li>
+ </ul>
+ </li>
+ <li>
+ <code>JspTestCase</code> : provides all JSP objects
+ <ul>
+ <li>
+ <code>pageContext</code> (of type <code>PageContext</code>),
+ </li>
+ <li>
+ <code>out</code> (of type <code>JspWriter</code>).
+ </li>
+ </ul>
+ </li>
+ </ul>
</li>
<li>
- Definition of a <code>beginXXX()</code> method for each
<code>testXXX()</code>
- test method. This is for having a chance to initialize the following
- data that will be available in the <code>HttpServletRequest</code> object
- in your test method :
+ Definition of an optional <code>beginXXX()</code> method for each
+ <code>testXXX()</code> test method. This is for having a chance to
+ initialize the following data that will be available in the
+ <code>HttpServletRequest</code> object in your test method :
<ul>
<li>
HTTP parameters,
@@ -60,8 +123,9 @@
</li>
<li>
Simulated URL. You can simulate all the parts of a URL : server
- name, port, context path, servlet path, path info and the query
string.
- The following methods will return the simulated parts :
+ name, port, context path, servlet path, path info and the query
+ string. The following methods, when used later in your code under
+ test, will then return the simulated parts :
<ul>
<li>
<code>HttpServletRequest.getServerName()</code>,
@@ -89,9 +153,9 @@
</ul>
</li>
<li>
- Definition of an <code>endXXX()</code> method for each
<code>testXXX()</code>
- test method. This is for having a chance to check the following data
- from the returned HTTP response :
+ Definition of an optional <code>endXXX()</code> method for each
+ <code>testXXX()</code> test method. This is for having a chance to
+ check the following data from the returned HTTP response :
<ul>
<li>
HTTP headers,
@@ -124,15 +188,18 @@
</ul>
</li>
<li>
- Predefined Ant 1.3 build scripts that show how to automate Cactus
+ Predefined Ant build scripts that show how to automate Cactus
unit tests (automatically starting your servlet engine, running the
- tests and stopping your server). There are scripts for the following
- Servlet engines :
+ tests and stopping your server). There are scripts provided for the
+ following Servlet engines (but it is easy to add new engines) :
<ul>
<li>
- Tomcat 3.2.1 (Servlet API 2.2)
+ Tomcat 3.2 (Servlet API 2.2)
</li>
<li>
+ Tomcat 3.3 (Servlet API 2.2)
+ </li>
+ <li>
Tomcat 4.0 (Servlet API 2.3)
</li>
<li>
@@ -148,15 +215,11 @@
WebLogic 5.1 (Servlet API 2.2)
</li>
<li>
- Orion 1.4 (Servlet API 2.2)
+ Orion 1.4 (Servlet API 2.2 and 2.3)
</li>
</ul>
</li>
<li>
- Possibility to modify the URL to which the Cactus Redirector servlet
- and Redirector JSP are mapped to (defined in a properties file)
- </li>
- <li>
Possibility to specify whether an <code>HttpSession</code> object
will be automatically created or not for your test methods
</li>
@@ -166,29 +229,21 @@
before and after calling each <code>testXXX()</code> method
</li>
<li>
- Tested with all versions of JUnit up to 3.7 included.
+ Tested with all versions of JUnit up to 3.7 included
</li>
<li>
Support for Servlet API 2.2 and 2.3 (Support for Servlet API 2.1 is
- not provided as it is now too old).
- </li>
- <li>
- Support for JDK 1.2 or 1.3 (not tested with 1.4 yet)
- </li>
- <li>
- Possibility to assert the returned servlet output stream from classes
- under test (in the <code>endXXX()</code> methods).
+ not provided)
</li>
<li>
- Helper classes to help assert cookies returned in the HTTP response,
- ...
+ Works with JDK 1.2 or 1.3 (not tested with 1.4 yet)
</li>
<li>
- Implicit objects are actually subclasses of standard servlet
- objects and provides additional methods to help unit test your code :
+ Provides some additional methods in the implicit objects that are
+ not part of the standard APIs to help you unit test your code :
<ul>
<li>
- Using the <code>config</code> implicit object :
+ In the <code>config</code> implicit object :
<ul>
<li>
<code>setInitParameter(String, String)</code> : sets a
@@ -203,6 +258,11 @@
</ul>
</li>
</ul>
+ </li>
+ <li>
+ Support for unit testing simple Tag libraries that do not use the
+ <code>bodyContent</code> object (this is a current limitation that
+ will be removed in the next version)
</li>
</ul>
</s1>
