vmassol 01/07/07 08:52:22
Modified: cactus/docs/framework/xdocs doc-book.xml index.xml
site-book.xml
Added: cactus/docs/framework/xdocs cactusv2.xml
Log:
addition of a proposal for Cactus v2
Revision Changes Path
1.15 +1 -0 jakarta-commons/cactus/docs/framework/xdocs/doc-book.xml
Index: doc-book.xml
===================================================================
RCS file: /home/cvs/jakarta-commons/cactus/docs/framework/xdocs/doc-book.xml,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- doc-book.xml 2001/07/05 12:57:54 1.14
+++ doc-book.xml 2001/07/07 15:52:22 1.15
@@ -29,6 +29,7 @@
<menu label="Design">
<menu-item label="Architecture" source="architecture.xml"/>
<menu-item label="Mock vs Container" source="mockobjects.xml"/>
+ <menu-item label="Cactus v2 proposal" source="cactusv2.xml"/>
</menu>
<menu label="User Guides">
1.17 +9 -0 jakarta-commons/cactus/docs/framework/xdocs/index.xml
Index: index.xml
===================================================================
RCS file: /home/cvs/jakarta-commons/cactus/docs/framework/xdocs/index.xml,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- index.xml 2001/07/05 12:57:55 1.16
+++ index.xml 2001/07/07 15:52:22 1.17
@@ -47,6 +47,15 @@
<table>
<tr>
<td>
+ 07/07/2001
+ </td>
+ <td>
+ <link href="cactusv2.html">Proposal for Cactus v2</link>.
+ Please give us your feedback.
+ </td>
+ </tr>
+ <tr>
+ <td>
05/07/2001
</td>
<td>
1.14 +1 -0 jakarta-commons/cactus/docs/framework/xdocs/site-book.xml
Index: site-book.xml
===================================================================
RCS file: /home/cvs/jakarta-commons/cactus/docs/framework/xdocs/site-book.xml,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- site-book.xml 2001/07/05 12:57:57 1.13
+++ site-book.xml 2001/07/07 15:52:22 1.14
@@ -29,6 +29,7 @@
<menu label="Design">
<menu-item label="Architecture" source="architecture.xml"/>
<menu-item label="Mock vs Container" source="mockobjects.xml"/>
+ <menu-item label="Cactus v2 proposal" source="cactusv2.xml"/>
</menu>
<menu label="User Guides">
1.1 jakarta-commons/cactus/docs/framework/xdocs/cactusv2.xml
Index: cactusv2.xml
===================================================================
<?xml version="1.0"?>
<!DOCTYPE document SYSTEM "./dtd/document-v10.dtd">
<document>
<header>
<title>Proposal for Cactus V2</title>
<authors>
<person name="Vincent Massol" email="[EMAIL PROTECTED]"/>
</authors>
</header>
<body>
<s1 title="Forewords">
<p>
This document is only a <strong>Proposal</strong> for Cactus v2.
We'd like to have your feedback. You have the chance to influence the
direction of Cactus, please do not hesitate to state your opinion
(either positive or negative) on the
<link href="mailinglist.html">Cactus mailing list</link>.
</p>
</s1>
<s1 title="Goal/Rationale">
<p>
The goal of Cactus v2 is to make it the framework of choice for testing
server-side java code. Notice that this differs from Cactus v1 as the
goal is now broader than just "unit test". Please note that the goal
is _not_ to provide a framework for performing acceptance tests nor
system integration tests, nor graphical regression tests, ... The goal
is still to perform test from inside but rather to encompass unit tests
and also functional tests. However, by functional test we mean to
be able to assert the result of calling a single dynamically generated
page and not a complete use case (HttpUnit style). Regarding unit
tests, Cactus v2 will
provide both <link href="mockobjects.html">Mock Object</link> style unit
tests and in-container style unit tests (same as with Cactus v1).
</p>
<p>
Why ? Why extend the scope ? One reason is that we see value in
providing a single consistent framework for performing these tasks
rather than having to use/learn several different frameworks (Mock
Objects, Cactus, HttpUnit, ...). The other reason is that you have
been several to request these features on the Cactus mailing list for
the past months. Another reason is that in-container style tests are
not a best-for-all solution and is nicely complemented by mock objects
style tests (or the other round !) and functional tests.
</p>
<p>
Testing server-side code implies the following different kind of tests:
</p>
<ul>
<li>
<strong>Business Logic unit tests</strong> : this will be tested
using the mock object test features of Cactus,
</li>
<li>
<strong>Container interaction tests</strong> : this will be tested
using the in-container test features of Cactus,
</li>
<li>
<strong>Test the interaction between client side code and server side
code</strong> (to test for example that cookies sent by the client
side can be read on the server side, ...) : this will be tested
using the functional test features of Cactus,
</li>
<li>
<strong>Test the results</strong> (i.e. validate that the pages
returned to the client side contain the correct data) : this will
be tested using the functional test features of Cactus,
</li>
<li>
<strong>Test the deployment of the code</strong> (i.e. verify that
the web.xml is correctly defined, ...) : this will be tested using
both the in-container and functional test features of Cactus
</li>
</ul>
<p>
Consequently, we can see that the goal of Cactus will be to fully
test, in a comprehensive manner, the server-side code. Cactus will
provide these features in a very flexible way, meaning that it will be
possible for each test case to exercise only one kind of test (as
defined above) or to exercise all the tests at once.
</p>
<p>
Most importantly, there will be only one format for writing test cases
that will work for all the different kind of tests, thus preventing the
user from having to learn different formats and also providing maximum
flexibility for combining the different kind of tests.
</p>
<p>
Another very important goal of Cactus will be to also provide a
methodology for performing server side tests. It will explain when to
write which kind of test and how it will integrate in the development
environment and within the build and deployment processes.
</p>
</s1>
<s1 title="TestCase format">
<p>
A test case will still be a JUnit test case, meaning that all tools
that run JUnit test cases will also run Cactus test cases.
</p>
<p>
A test case will have to extend a Cactus class (ServletTestCase for
testing classes in the servlet environment).
</p>
<p>
Each test case will be allowed to define a <code>beginXXX()</code>
method. In this method, you will be able to define all the client
side environment for the test, i.e. set HTTP paramater that you will
retrieve in the Servlet request, cookies, HTTP headers, forms to send,
... Everything that Cactus v1 was offering will still be there and
additional useful methods will be added (see HttpUnit). There will still
be methods to simulate a URL as in Cactus v1.
</p>
<p>
In addition, there will be a method to define the URL that will be used
to connect to the server code. Depending on the kind of test you
want to perform, it will be set to :
</p>
<ul>
<li>
A redirector servlet for in-container tests. Note that it will
be possible to define several redirector servlets in the web.xml
file so that different configuration could be used,
</li>
<li>
The page to test for functional tests. For example, if you wish to
test the result of the execution of a JSP, you will put the URL
to this JSP. [Note that it is possible to combine in-container tests
with functional tests by setting this URL to a redirector servlet]
</li>
<li>
Nothing for mock objects tests. No real HTTP connection will be made.
</li>
</ul>
<p>
Note that the <code>beginXXX()</code> method will be optional and if
none is setup then the test will be a mock object test (as no URL
will have been defined).
</p>
<p>
Each test case will have a <code>testXXX()</code> method (for pure
functional tests, this method will be empty). You will be able to
initialize server side objects (like putting a value in the HTTP
session, or adding an attribute to the page context, ...). This
method will also contain the call to the method to unit test and will
contain all the assert conditions for verifying object values on the
server side.
</p>
<p>
Each test case will be allowed to define a <code>endXXX()</code>
method. This is where you will be able to verify what has been sent
back by your server code. You will be able to verify cookies, HTTP
headers, and all content of the returned data. The returned data will
be exposed as a DOM and several methods will be provided to search
for given elements (like get the second returned table and verify that
the background color is such, ...) [same as HttpUnit].
</p>
<p>
In addition to these test cases, a web.xml file will have to be
provided for in-container tests (to map the redirector servlet) and
functional tests involving servlets, tag libs, ...
</p>
</s1>
<s1 title="Conclusion">
<p>
What would be really great would be to closely integrate with HttpUnit
for the client side test features and the returned data validation.
</p>
<p>
Please tell us what you think, whether this is a honorable goal or not,
where you see big issues that will ba heard to overcome, ...
</p>
<p>
Thanks again for your participation in this pioneer project in the realm
of server side testing !
</p>
</s1>
</body>
</document>
