Unlike most developers Vincent Massol thinks tests are fun. Not just any tests, though, “We try to make it fun, as well as useful, by automating the tests. They run after the nightly build, and the result is sent via e-mail to the developer. It’s great when you receive good news in the morning.”
Massol is a consultant with France-based Octo Technology (he is currently working from London to setup Octo’s newest subsidiary).
As a software architect, his special sweet spot is unit testing. Unit tests validate each method independently; they operate at a much finer granularity than the more familiar functional tests. The latter treats the classes as a black box and simulates the users while unit tests know about the class’s inner working and specifically try to break it.
The two testing strategies are complementary: unit tests may reveal intricate bugs that functional testing would miss, but functional tests are required to validate the application’s overall performance.
“Unit tests are not new but they were popularized by XP (eXtreme Programming),” explains Massol. “Also, tools like the nightly build have made them practical.”
The most popular framework for unit testing in Java is JUnit, but Massol found it lacking for server-side testing.
More specifically, the problem arises due to dependencies on server-provided objects. Unlike a standalone application, servlets and EJBs depend on objects created and managed by the server. For example, many servlet methods expect an HttpServletRequest and an HttpServletResponse object as parameters, making it impossible to test the methods without valid instances of these objects.
“There are two strategies around this problem: mock objects and in-container tests, as done by Cactus,” adds Massol. Mock objects were introduced by Tim Mackinnon, Steve Freeman, and Philip Craig. The concept is simple: developers create test replacements for server objects. For obvious reasons, these objects hold as little logic as possible (otherwise, they would require testing too!) and are limited to returning test values. The name “mock objects” indicates that they are not true server implementations.
By definition, the mock objects strategy does not test against a real server. There’s a risk that the tests yield different results than deployed code. Furthermore, even though they are dramatically simplified, mock objects still require a development effort.
The alternative is to run the tests on the server, using real objects provided by the Web server. Massol wrote several of these frameworks for his customers. As he gained experience with the technique, he decided to consolidate his results in an open source framework.
Why go open source? “It fits our culture,” says Massol. “As a company, we believe in sharing. Also, the more developers use it, the more we and our customers benefit.”
The first version was released on SourceForge; but when he learned that Apache Jakarta wanted to start work on testing tools, Massol knew he had found the right community. He renamed his project Cactus (the original name, J2EEUnit, infringes on a Sun trademark) and moved to a new home under Jakarta Commons.
A Testing Service
So far, Cactus works well for servlets, but EJBs, which have even more dependencies on server objects, are tougher. Massol may have a solution, though. “The EJB container should have a new testing services, alongside the other services such as persistency or transaction.” He is working on such a framework.
Till Next Time
If you want to propose a project — whether open source or commercial — or comment on this column use the feedback form at marchal.com.
About the Author
Benoît Marchal is a Belgian developer and writer. He is the author of XML by Example and Applied XML Solutions.