This is one of the things I've been pushing for awhile. To extract the basics of our testsuite into a downloadable library as well as provide ant templates and documentation so that others can use this stuff.
I have already identified the files that should be extracted. Anybody care to document this stuff and maintain the JBoss test framework for others to use? There's CVS RW in it for you. XXXXXXXXXXXXXXXX Bill Burke Chief Architect JBoss Group, LLC XXXXXXXXXXXXXXXX > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Dain > Sundstrom > Sent: Tuesday, December 10, 2002 6:37 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-user] Re: Testing EJB's > > > The exact same thing has existed in JBoss for a long time and is called > JUnitEJB... I really think it should be converted to be an MBean > instead, but that is another story. > > -dain > > On Tuesday, December 10, 2002, at 05:00 PM, SPam wrote: > > > Dain, your are right its a good approach to test EJB tier to have test > > run > > inside the container. > > > > Jim, There are interesting things in JBoss source, and there is also a > > demoniac Junit extensions called ServerTestCase which uses as a custom > > test > > runner a simple stateless (remote) EJB which runs your test case > > inside the > > container and can be call like a standard junit test case ie thru > > jndi. You > > still write only one classe for your TestCase, which will be both the > > test > > case caller thru the JVM running your tests and the test itself called > > in > > the TX of the stateless remote EJB. > > (mmh, not that clear, but if u look in the internal details of JUnit, > > you'll > > see how this approach is demoniac) > > > > The distributed ServerTestCase is for weblogic (6), but very easy to > > adapt > > for JBoss or any app server you want. > > http://www.junit.org/news/extension/j2ee/index.htm#ServerTestCase > > > > I just think you have to be carefull with TestSuite and setUp() > > tearDown() > > usages. > > > > S.Pam > > > > > > "Dain Sundstrom" <[EMAIL PROTECTED]> wrote in message > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > >> 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/ > > > > > > > > > > > > > > ------------------------------------------------------- > > 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
