JakartaCactus
Last edit August 10, 2006Cactus is a simple TestingFramework for unit testing server-side JavaLanguage code (JavaServlets, EnterpriseJavaBeans, TagLibs, Filters, ...).
The intent of Cactus is to lower the cost of writing tests for server-side code. It uses JavaUnit and extends it.
Cactus implements an in-container strategy.
Cactus Wiki
Cactus Home Page
Mailing Lists
Cactus is also good for AutomatedAcceptanceTesting. It now includes HttpUnit. It can send HTTP requests to a server and verify the response. The primary benefit of Cactus for UnitTest is that J2EE context objects like servlet requests, servlet config, init parameters are very hard simulate with MockObjects.
Can someone who's done TDD with a web project tell me when in-container testing is necessary? I'm finding I do great with straight unit tests, and HttpUnit AcceptanceTests. Also, doesn't it bother in-container people that they have to have test code in the server during development? Seems like ideally you'd want to hit a pure production-like environment...
I find Cactus invaluable for unit testing EJBs (particularly those deployed with local interfaces only), and the combination of cactus and remote debugging makes developing EJBs (almost) as simple as writing vanilla java objects
Cactus Wiki
Cactus Home Page
Mailing Lists
Cactus is also good for AutomatedAcceptanceTesting. It now includes HttpUnit. It can send HTTP requests to a server and verify the response. The primary benefit of Cactus for UnitTest is that J2EE context objects like servlet requests, servlet config, init parameters are very hard simulate with MockObjects.
Can someone who's done TDD with a web project tell me when in-container testing is necessary? I'm finding I do great with straight unit tests, and HttpUnit AcceptanceTests. Also, doesn't it bother in-container people that they have to have test code in the server during development? Seems like ideally you'd want to hit a pure production-like environment...
I find Cactus invaluable for unit testing EJBs (particularly those deployed with local interfaces only), and the combination of cactus and remote debugging makes developing EJBs (almost) as simple as writing vanilla java objects