Roadmap/Todo for Cactus

Last update : April 21 2002
Doc for : v1.3

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
  • Security Howto
  • Ant Howto
  • HttpUnit Howto
  • Sample Howto
  • EJB Howto
  • IDE Howto
  • JUnitEE Howto


  • Support
  • Bug database
  • Mailing list


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


  • Developers
  • CVS
  • Coding Conventions
  • Build results


  • 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.4

    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 
    Configure all supported containers with authentication so that they pass the Cactus unit tests (done for Tomcat 3.x + Tomcat 4.x).   Peter Wong, Jason Robertson, Vincent Massol 
    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 
    Add support for Form-based authentication.   Peter Wong, Jason Robertson, Vincent Massol 
    Refactor/redesign the Cactus client side so that it can accept several kinds of protocol injectors (it now only supports HTTP). The idea is to be able to add first JMS so that Message-Driven Beans or simply JMS listeners can be unit tested.    
    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.    
    Consider using Commons Logging Wrapper as it provides seamless support for No Log, Log4J, LogKit and JDK 1.4 logging.    
    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 
    Consider moving from HttpURLConnection to Commons HttpClient. This will solve the problem of asserting code that returns an error response code. Note: this has been fixed in JDK 1.3.1 I believe for HttpURLConnection but as we're already using HttpClient for handling cookies (because the JDK does not seem to provide any API for that). Review JDK 1.4's HttpURLConnection to check if the JDK is making any progress in this area. In term of design, isolate the implementation with an interface so that different implementation can be plugged in without affecting any other business classes.    


    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.