EJB Unit Tests?
Seeing kbob's diary entry 1 Oct 2000 on
unit tests, I'm wondering how one would apply this to EJBs?
I've read a bit of the extreme programming concept and I
always thought it was a good idea but it needs the
participation of the entire team and to start applying it
to
an existing project seemed difficult.
But I digress. How to apply this to EJB? Just off the
top of myhead... Each EJB implementation class has an inner
class called UnitTest? And then any EJB can be tested by
creating an instance of that Bean's UnitTest inner class
and calling it's test method. For example:
public class FooBarBean implements SessionBean
{
public static class UnitTest extends AsbtractUnitTest
{
public void test()
{
...
}
}
...
}
A few notes:
- The UnitTest innerclass is static so that you can
create an instance of the UnitTest without an instance of
FooBarBean.
- The AbstractUnitTest class defines an abstract method
called test which is overridden in FooBarBean.UnitTest. I'm
not sure whether it should be an interface or an abstract
class. I went with abstract class because it provides the
option of providing helper methods and data in the abstract
base class (like logging, pretty printing, etc.) that can
be used by the UnitTest subclasses.
But this construct can be applied to any kind of Java
class. There are special considerations that need to be
made for EJBs. EJBs need to run in an EJB container. For
clients of those EJBs (i.e. the UnitTests) to access them,
they need to have the
container-specific classes for accessing that container on
the classpath, they need to know what class to use as the
JNDI provider, what JNDI URL to look up objects in, JNDI
authentication details (if any), etc. Now one could either
put in infrastructure (possibly in AbstractUnitTest) to
handle configuring all that when running the unit test or
one could fake it. By faking it, I mean faking the fact
that the EJB is running in an EJB container.
An EJB implementation class is a passive thing. It is
called by the container to perform various operations
(create, load, store, active, passivate, etc.). Thus, just
like an EJB container generates implementation classes for
the Home and Remote interfaces which call upon the EJB's
implementation class, the unit testing framework could do a
similar thing. However, this means that extra classes need
to be generated and compiled just for unit testing which
may not be desireable. One solution could be to use generic
implementation classes that use the Dynamic Proxy Class technique available in
JDK1.3
Yeesh, I yak too much. Basically, I think it would be
possible to build a generic EJB unit testing framework but
it's not trivial. ;)