Roadmap/Todo for Cactus

Last update : September 25 2001

About
  • What is Cactus ?
  • Features/Status
  • Goals
  • News/Changes
  • Roadmap/Todo
  • Contributors
  • Contributing
  • License
  • Feedback


  • Downloads
  • Downloads


  • Documentation
  • How it works ?
  • Getting Started
  • Mock vs Container
  • API Reference


  • Howto Guides
  • Config Howto
  • TestCase Howto
  • Ant Howto
  • HttpUnit Howto
  • Sample Howto
  • EJB Howto
  • IDE Howto


  • Support
  • Bug database
  • Mailing list
  • FAQ


  • Misc.
  • Why the name ?
  • Resources


  • Developers
  • CVS
  • Coding Conventions


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

    Design/Code

    Description  Volunteers 
    Provide some sample taglib tests.   Nicholas Lesiecki 


    Version 1.x where x>2

    Documentation

    Description  Volunteers 
    Add a tutorial for VAJava with Tomcat environment (the current tutorial on the web site is for VAJava with WTE). Needed steps are detailed on the cactus-user list, thread "Cactus, Apache Tomcat & VisualAge". Thanks to Jim Young.    
    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 

    Build Process

    All tasks that are related to building Cactus in general.

    Description  Volunteers 
    Add Ant scripts to support WebLogic 6.0.    
    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.    
    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 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 an API in WebRequest to send data to the URL connection output stream. This is, for example, to easily test code that upload files to a servlet. This would need managing "multipart/form-data" MIME type in the HTTP connection. A convenience method, like WebRequest.uploadFile(InputStream) should be added. We should wait till Cactus moves to using commons-httpclient for HTTP connections (in replacement of HttpURLConnection).    
    Design and implement a mechanism for better supporting unit testing of EJBs (they are currently supported). There are several possible mechanisms :
    • in-container, calling the remote methods from the testXXX() methods by providing a helper class that looks up the home interface, create an instance and call the method,
    • in-container, by providing an EJB Redirector which is itself an EJB (and thus has access to container objects) and just call the EJB method to test as a standard java class, providing implicit objects to an EJBTestCase that user need to derive (exactly the same mechanism currently used for Servlets),
    • others ?
     
     
    Support unit testing of Servlet code that uses Security APIs, such as isUserInRole(), ...    
    Find a mechanism to instanciate Log4j just for Cactus and not interfere with a user using Log4j in it's code. At the current time, Cactus reconfigure Log4j at init and thus will invalidate the configuration of a Cactus user or that user will have to add the Log4j configuration for Cactus in its own config file.    
    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 

    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.    
    When we want to unit test classes written for the Struts framework (for example), we can use Cactus to provide access to all Servlet API implicit objects. However, there is still a need to get access to Struts implicit objects (for example, calling the perform() method of an Action class need to get hold of several Struts object beforehand). A solution might be to provide some factory helper classes to provide these objects. This could go in a org.apache.cactus.util.struts package but will need to be maintained and synced with Struts versions. Another solution might be to host these helper classes within Struts itself. We need to think about that (same issue as with Ant custom tasks - There have been lengthy discussion on the subject on the Ant mailing list). Another solution is to use Struts Mock Objects (could be done as part of the SourceForge Mock Objects project - www.mockobjects.com).    




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