|
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
|
General goals |
-
Provide a simple unit testing framework focused on server side java
code which tries to cover all J2EE component models,
-
Try to be the preferred Jakarta unit testing framework. This may
mean providing specific extensions to ease writing unit test for
Jakarta frameworks (like for Struts, Turbine, ...),
-
To be the framework of reference for in-container unit testing
strategy,
|
Short terms goals |
The short term goals for Cactus are to provide unit-testing for :
-
Servlets,
-
Servlet 2.3 Filters,
-
Tag libraries,
-
EJBs
|
Long term goals |
The Future of Component Unit Testing |
We believe unit testing server side components is going to get harder
and harder in the future (unless something is done about it !).
Even now, depending on the specifications
for a given component model it is more or less easy. Sometimes it is
even not feasible to test all kind of code.
We believe that we will see more and more components in the future.
By components we mean pieces of code that execute in a container.
The container will provide more and more services for the components
(like transactions, security, life cycle, persistence, interfaces
- like web services -, logging, ...). The consequences will be :
-
testing strategies that are not in-container, like Mock Objects
will become less useful. Indeed, as the components will rely
more and more on the container's services, the confidence that
the tests will run well when deployed will decrease and the need
for a solution that ensures the code will run correctly in it's
environment will increase,
-
it will become more and more difficult to offer an in-container
unit testing framework that lives outside the container.
|
Long term goals for Cactus |
Consequently to the above prediction, there are 2 long term goals
for Cactus :
-
Continue with the in-container approach as much as possible. It is
a best try effort in order to provide tests in which you can have
a good confidence,
-
However, we believe the only satisfactory and long term solution
is to include (unit) testing APIs as part of the container
specifications. This could be done in the form of a SPI
(Service Provider Interface) against which a generic unit testing
framework could be plugged, thus leaving the implementation details
to an external framework and only providing maybe a generic
and simple implementation. Thus, the goal of Cactus will be
to help specify needed container API/SPI for unit testing,
i.e. create
an additional service of the container : a "unit-testing service"
(in addition to the existing Security, Transaction, Life Cycle, ...
Services). As Cactus and Tomcat projects are both hosted on Jakarta
it might be a good test ground for this kind of work. Of course,
the first step would be to convince Tomcat developers that unit
testing (and testing in general) is indeed a need to be
addressed in the container itself. The ultimate
goal will be reached when this new API/SPI is accepted and become
a de jure standard. It would then be time to think about
integrating it into the Servlet Specifications
(or other components -like EJBs -
specifications). Agreed, this far-streched at the current time
but it is the Cactus' vision !
|
|
Feedback needed ! |
Cactus is an open source project where everyone is free to participate
(and even encouraged). Thus, we'd really like to have your opinions on
the subject of Cactus future.
How do you view the future of Cactus ?
Do you like the goals defined above ?
Do you think it is feasible ?
Please send all answers to the
Cactus mailing list.
Thanks.
|
|
|