Ant can be used to automate an EjbUnitTest
, but there
are several possible approaches, most centering on
custom extensions to Ant.
There's been discussion on the ant-user mailing list
under the threads "Weblogic and Junit", "<wlrun> and j2eeunit",
"Running junit tests that access EJBs", and "Custom WLUnit task", among others.
So far, there seem to be four different approaches:
1. Use a shell script to control the server and coordinate with the build, like this:
2. Use the customized version of the wlrun task from ThoughtWorks
, and the custom sleep and waitforlogevent tasks, to start the server, run junit tasks, and stop the server all in one build.
3. Use the custom runservertests task from the Cactus project to run your start-server target, junit target, and stop-server target all in one build (see http://jakarta.apache.org/cactus/integration/ant/index.html
4. Use the custom wlunit task (http://www.gis.net/~jimdoyle/wlunit/wlunit.shtml
) by JimDoyle
to start the server, run junit tests, stop the server, and wait for server process exit, all in one task (and therefore in one build).
All of these tasks centre around using WebLogic
for development and testing. One of the major reasons for this is that WebLogic
does not properly support dynamic (re)loading of classes, especially EAR files (see WebLogicGripes
for more on this). This means that, for most practical purposes, you end up needing to stick the classes on WebLogic
's system class path, which in turn means that you need to restart WebLogic
whenever you want to change those classes. (This bug is meant to be fixed in 6.1, which is slated for a June/July release)
There are appservers out there that properly support dynamic loading and reloading of classes. OrionServer
, in particular, looks promising to me at this time. With such an appserver, you leave the server running all the time (just as you leave your database running all the time), then simply build the EJB/EAR and deploy it (usually by copying the file into a deploy directory). The other advantage of it, of course, is that you can stick a copy on every developer's box. -- RobertWatkins
I've done exactly that, with OrionServer
on every developer's box, in a previous project. It worked out very well, but I would have preferred to use mock objects instead of a full J2EE server to avoid the startup time. But building mock objects for the J2EE interfaces didn't seem realistic. --AndersBengtsson
Do it a bit at a time... A combination of MockObjects, plus an adaption of BusinessInterface, lets me test the business logic of my code with reasonable confidence, letting me push back the full-scale testing for integration time. -- rw