Roadmap/Todo for Cactus

Last update : July 29 2002
Doc for : v1.4b1

About
  • What is Cactus ?
  • News
  • Changes
  • Features/Status
  • Goals
  • Roadmap/Todo
  • Contributors
  • Contributing
  • Cactus Users
  • Tested on ...
  • License


  • Downloads
  • Downloads


  • Documentation
  • How it works ?
  • Getting Started
  • Mock vs Container
  • Javadocs
  • FAQ


  • Howto Guides
  • Classpath Howto
  • Config Howto
  • Migration Howto
  • TestCase Howto
  • Runner Howto
  • Security Howto
  • Ant Howto
  • HttpUnit Howto
  • Sample Howto
  • EJB Howto
  • IDE Howto
  • Tomcat Howto
  • JUnitEE Howto


  • Support
  • Bug database
  • Mailing list


  • Misc.
  • Why the name ?
  • Logo Challenge
  • Resources
  • Test Coverage
  • Stats


  • Developers
  • CVS
  • Coding Conventions
  • Build results
  • Release Checklist


  • Forewords

    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 ... !


    Version 1.5

    Documentation

    Description  Volunteers 
    Move all documentation to docbook and cocoon2 and generate PDF containing full Cactus documentation. Note: I still need to find out how to make Cocoon2 generate errors during generation of doc. so that the Ant build reports an error and stops upon finding one.   Vincent Massol 
    Add a tutorial for building Cactus from the source distribution.    
    Write a tutorial that explains how to use Cactus to do unit testing of JSP, i.e. only test the JSP itself and not the controller part and the model (only test the View in an MVC model). This is done by using mock implementations of java beans used in the JSP to unit test, set these java beans in the testXXX() method of a cactus test and then assert the result of the JSP executing in the endXXX() method.   Jari Worsley 
    Add some documentation (possibly in the FAQ) to explain how to unit test Struts classes (refer to the StrutsTestCase project).    

    Build Process

    All tasks that are related to building Cactus in general.

    Description  Volunteers 
    Finalize support for Enhydra 3.1.1. There are some errors upon starting the enhydra server and the testOut() method is failing. Need help from Enhydra experts to go forward.   Bob Tanner 
    Add the Ant scripts for JBoss 2.x w/Tomcat provided by Jeffrey Madynski (jmadynski@food.com) on the jakarta-commons mailing list (Subject "[cactus] Using Cactus with JBoss-2.2.1 with Embedded Tomcat"). The scripts need to be reworked so that the deployed test war is deployed within the target output directory and not to where JBoss/Tomcat is installed.    

    Design/Code

    Description  Volunteers 
    Write a JMS Redirector/Client to test Message Driven Beans.    
    Add support for Form-based authentication.   Peter Wong, Jason Robertson, Vincent Massol 
    Add methods that are called before and after each test, but on the client side (i.e. before the beginXXX() and endXXX() methods). They would act the same way as setUp() and tearDown() but on the client side. They could be named init() and destroy(), or maybe we should rather rename the existing setUp() and tearDown() and have something consistent like : setUpClient(), setUpServer(), tearDownClient() and tearDownServer() ?    
    Provide support for generating Session cookies and URL Sessions (URL rewriting). A description of the mechanism has been posted in thread "How does cactus simulate a session" on the Cactus user mailing list. Thanks to Kyle W. Willkomm.    
    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 an EJB sample application to demonstrate how to perform EJB unit testing (the tutorial that explains the process will be part of Cactus 1.2 but the inclusion of the sample will be delivered in a subsequent release as it involves some changes in the build process).   Hudson Wong, Vincent Massol 


    Undefined

    Ideas

    Ideas to explore ...

    Description  Volunteers 
    Create a new package org.apache.cactus.extensions for putting extensions to Cactus Test Cases. The first extension would be an extension that runs a bunch of test at the same time, thus spawing several threads in the container in order to discover bugs [Note: We would have to correct the name under which Cactus test results are stored in the application context so that it is unique per test case]. We would need to create a org.apache.cactus.extensions.ParallelServletTestCase. The constructor would take some parameters, such as the number of parallel threads to spawn, ... Idea suggested by Michael Rimov.    
    Use XDoclet with Cactus to better provide continuous integration. It could be used to automatically generate web.xml files, automatically generating test cases from methods to test, ...    
    Integration to Netbeans in general and especially integration with the Netbeans XTest module.    
    Evaluate the use of AspectJ for writing Cactus test cases.   Vincent Massol 
    Help Cactus users test multipart/form-data. At least explain how to do it. Some idea: use cos.jar (from http://www.servlets.com/cos/index.html) to read multipart/form-data on the server side. Now 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 need to check if it has this feature or if it can be added. Submitted by Gunnar Ole Skogen.    




    Copyright © 2000-2002 The Apache Software Foundation. All Rights Reserved.