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

Reply via email to