6 Nov 2000 doxxx   » (Journeyer)

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. ;)

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!