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

( http://marc.theaimsgroup.com/?l=ant-user&r=1&w=2 )

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:
"ant build
 startWebLogic.sh &
 sleep 20
 ant test
 stopWebLogic.sh
 sleep 20"

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 MockObject''''''s, 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''

----
CategoryAutomated CategoryTesting