This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
We are planning to add a testing framework for our J2EE web services and servlet project. We're looking at Cactus but I saw the following on the Wikipedia entry for Cactus:
According to a posting on the official Cactus development email list , development on Cactus has largely stalled. The current version of Cactus, 1.7.2, was released on 2006-03-26 and does not support Junit 4.
Any idea why Cactus development has slowed down, and in your opinion is Cactus still a robust platform for J2EE/JEE testing?
I've mentioned this in a couple of other threads, and the short answer is no, I dont think cactus is a good idea at all.
There are a number of other solutions that can investigate. The ideal, of course, is to develop your code such that it can run outside of a container. That way its much easier to test and you eliminate the need for all these 'middle man' frameworks that are often awkward and uncomfortable to use. The barrier to writing tests is also lower which makes them more likely to get written.
This is particularly true for servlets. Any decent webservices engine has a servlet as a very thin frontend to the actual 'meat' of WS, to ensure that they're not tied to that environment. Your code should be the same!
Similarly for pretty much any other container bound technology. In the book we go through a whole range of Java EE APIs and show how they can be tested outside of a container, including JPA, JMS, JTA, JDBC (DataSources), JNDI, and so on.
If you do want to test in-container, then we also show how that can be done, via embedding TestNG into your app. That way when tests are run, they are run inside of the container, and you can have whatever UI you want to drive them or to get reports and so on.