There is an example in the jboss/testsuite/buid.xml of an ANT target that starts up JBoss, runs JUnit tests and then shutsdown JBoss.
Note that this stuff hangs on Windows because of pause commands in the bat files launched in the background (unless fixed in the last couple weeks) and the shutdown command not only has a non-backward compatible arg format between 3.0.x and 3.2.x, but there are limitations on the JVM the server is compiled with and running with - I believe due to Java's godawful serialization ids. Not the same JVM as JUnit, but the next best thing for automated tests. I can give more info on how I used this stuff if you are interested. -Fred -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dain Sundstrom Sent: Wednesday, December 11, 2002 12:29 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Testing EJB's If you want to test in JBoss, you will need to have JBoss running somehow. Unless you are running on a very old machine, the JBoss start up should be start fairly quickly (under 30 sec). I usually just leave a JBoss instance running, and test over and over again. -dain On Wednesday, December 11, 2002, at 11:15 AM, Jim Crossley wrote: > Thanks, Dain. At first, I was encouraged by your reply, so I checked > out the source, but it doesn't address my needs. At least, the branch > I checked out (3.0 and jboss-head) could not run the testsuite > successfully without first firing up JBoss. > > I want to be able to test my CMP's in an in-memory, lightweight EJB > container that I can somehow quickly bootstrap from my JUnit > testrunner. The CMP's would persist for the duration of the tests in > the in-memory Hypersonic database. Perhaps EJB's are so resource > intensive that something like this isn't feasible? > > -- Jim > > Dain Sundstrom <[EMAIL PROTECTED]> writes: > >> Jim, >> >> How do you think we test JBoss? Take a look at the CMP tests in the >> testsuite. We have an addon to JUnit that can deploy and undeploy >> applications. Also we have a tool that can run the tests on the >> server side like (I wrote this to test local interfaces), but does not >> require a servlet tier. >> >> >> -dain >> >> >> On Tuesday, December 10, 2002, at 02:23 PM, Jim Crossley wrote: >> >>> These are good points, and I appreciate yours and others' prompt >>> replies. However, the solutions presented so far seem to force me >>> to complicate my object model to facilitate testing. >> >>> >>> I agree that an app that is difficult to test probably suffers from >>> poor design, but web apps by their very nature are difficult to test. >> >>> >>> The app I'm currently working on is very CRUD-ish; it does simple >>> read/write maintenance on a bunch of related objects. I don't want >>> the web tier to access the Entity beans directly -- this would >>> violate the transactional requirements -- so they go through a >>> Session Facade. Creating additional POJO's through which the session >>> beans interact with the entities only adds an unnecessary layer of >>> complexity IMHO. >> >>> >>> The app is currently implemented using OJB, and I'm interested in >>> refactoring it to use CMP EJB's, which IMHO are much easier to >>> create and maintain (with Xdoclet, of course) than OJB. >> >>> >>> The big benefit of using OJB, however, is that a user can easily >>> test the entire app from end-to-end without deploying or even >>> interacting with an external resource. This is possible with >>> Hypersonic's in-memory database. It got me thinking that an >>> in-memory EJB container would be just as cool. >> >>> >>> JBoss is architected so well that I figured there must be a way to >>> do it. I'm currently trying to add enough stuff to the minimal >>> configuration to support the deployment of EJB's, and then I'll see >>> if it's not possible to invoke that configuration from the setup of >>> my JUnit test runner. >> >>> >>> Does anyone else think this is possible or even worth pursuing? >>> >>> -- Jim >>> >>> Demyanovich, Craig - Apogent wrote: >>>> Jim, >>>> I currently do not unit test either Entity or Session Beans. >>>> Entity Beans >> >>>> are trivial to write, and I trust that the application server will >>>> persist >> >>>> them as advertised. To unit test Session Beans would require that >>>> they be >> >>>> deployed. Since deployment complicates unit testing and >>>> complicated or >> >>>> difficult unit tests suggest that the design could be done >>>> differently/better, I design Session Beans to be controllers of a >>>> number of >> >>>> collaborating objects. These objects are simply business objects >>>> that >>>> encode the business logic of the system. Since they are plain Java >>>> classes, >> >>>> I can unit test them very easily. >>>> Consider a message-driven bean. As I generally design them, MDBs >>>> receive a >> >>>> message, hand it to a parser, hand the results of parsing to other >>>> objects >> >>>> that do something with the message contents, hand the results of >>>> that work >> >>>> to a communictator, which knows how to send the final results where >>>> they >> >>>> need to go. So, I don't test any part of the MDB; rather, I test >>>> the >>>> various collaborating business objects. If I'm confident that they >>>> all >> >>>> behave as expected, I'm confident that they will also do so when >>>> they >>>> interact via one another's interface. >>>> Hope that helps, >>>> Craig >>>> ------------------------------------------------------- >>>> This sf.net email is sponsored by:ThinkGeek >>>> Welcome to geek heaven. >>>> http://thinkgeek.com/sf >>>> _______________________________________________ >>>> JBoss-user mailing list >>>> [EMAIL PROTECTED] >>>> https://lists.sourceforge.net/lists/listinfo/jboss-user >>> >>> >>> >>> >>> >>> ------------------------------------------------------- >>> This sf.net email is sponsored by: >>> With Great Power, Comes Great Responsibility Learn to use your power >>> at OSDN's High Performance Computing Channel >> >>> http://hpc.devchannel.org/ >>> _______________________________________________ >>> JBoss-user mailing list >>> [EMAIL PROTECTED] >>> https://lists.sourceforge.net/lists/listinfo/jboss-user >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by: >> With Great Power, Comes Great Responsibility Learn to use your power >> at OSDN's High Performance Computing Channel >> >> http://hpc.devchannel.org/ >> _______________________________________________ >> JBoss-user mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/jboss-user > > > ------------------------------------------------------- > This sf.net email is sponsored by: > With Great Power, Comes Great Responsibility > Learn to use your power at OSDN's High Performance Computing Channel > http://hpc.devchannel.org/ > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
