As is stated on the Cactus goals page, the intention is to explore as much as possible in the realm of unit testing of server side java code ...
This brings a bad news and a good one ... The bad one is that the TODO list is likely to keep growing or at least have a respectable size ... The good one is that there will be work for everyone ... :-)
If you are interested in participating, send an email on the Cactus mailing list stating your interest and you'll be enrolled right away ... We're always looking for help ! Don't be put off if in the "Volunteer" column there is already a person listed. On the contrary, the more person that participate in a given task, the better (like in pair programming, several sets of eyes are always better than one!). However you'll need to sync. with these others persons but this is easily done by posting to the mailing-list.
The game has just begun ... !
|Add documentation for form-based authentication.||Vincent Massol|
|Fix problems in changes.xml XSL stylesheet transformation so that HTML elements are not stripped (such as the <p> elements we have there).||-|
|Improve the documentation CheckSitemap Ant task to check external URLs (when online).||-|
|Rewrite "Quick start guide" to take into account the different front ends.||-|
|Fix the nightly Gump build so that the changes page get generated with the CVS changelog information. ATM, it's always empty which negates this nice feature...||-|
|Add an automated Maven build (using codehaus). See http://wiki.codehaus.org/general/CodehausBuildmeister.||-|
|Prevent the sample jetty project from building if the J2EE API is 1.2.||-|
|Add a Gump definition for building the Eclipse Site project and only released an installed Eclipse update web site (no zips). Same as what is on http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/org.eclipse.ajdt/download.html.||-|
|Add support in Ant Integration for the J2EE RI.||-|
Run JDiff before releasing to mark new classes/methods/members with
|Add EJB Redirectors so that unit testing of code that require an EJB is facilitated. For example, let's imagine you need to test that an object that has been put in the JNDI tree by a servlet can be retrieved by an EJB. These are not unit tests per see but rather integration tests, which is Cactus favorite domain. Also these redirectors could be used to directly unit tests EJB whithout requiring a servlet environment (at the current time, you need to call your EJB from a Servlet/JSP/Filter Redirector, which is fine for certain tests but not needed for others.||-|
|Add test case for form-based authentication.||-|
|Improve the ServletTestRunner: look at ways to make it run without the permission to set system properties.||-|
|Continue the JMS Redirector/Client to test Message Driven Beans.||-|
|Potentially replace access to instance variables of redirectors by method calls. For example, replace "request.xxx()" by "getHttpServletRequest().xxx()". Deprecate the direct access. Needs to be discussed on cactus-dev. Also, deprecate XXXTestCase in favor of test suites.||-|
|Add support for multi-concurrent Cactus tests. This involves storing each test result under a unique key in the application scope.||-|
Improve support for the JUnitReport XML format so that the Ant-provided
|Explore ways to improve the performance and design of the HTTP transport. Currently, each test invocation involves a new connection to the server. The HTTP/1.1 Keepalive feature could be used to reuse a single connection for all test invocations. Responses to the GET_RESULTS request do not need to include a body if there was no exception on the server-side. Possibly use custom HTTP headers to communicate the Cactus service parameters such as the name of the test class and method, instead of using query string parameters.||-|
Ideas to explore ...
|Add performance extensions to be able to test each single method in performance: response time. Need to add notion of server time in cactus XML response. And need extensions (probably TestSuite extensions to repeat each test or start several threads). Idea initially suggested by Michael Rimov. Integrate JUnitPerf.||-|
with Cactus to better provide continuous integration. It could be
used to automatically generate
|Add tutorial on Cactus and AOP unit testing (using AspectWerkz for example). Also research adding a Cactus Aspect extension to allow writing test cases as Aspects (this would allow to remove the need for Cactus redirectors in most cases).||-|
|Help Cactus users test multipart/form-data. At least explain how to do it. Libraries to help on the server-side include cos.jar and Commons FileUpload. Then we still need to provide a mechanism to easily send multipart/form-data on the Cactus client side. The best solution would be to use HttpClient but we are currently not exposing the HttpClient API so that it could be used in a test. Submitted by Gunnar Ole Skogen.||-|
|Provide a full servlet container test suite a la Watchdog using Cactus||-|