Junit testing on a stateless session bean

[david lightman]

Hi I have everything working in my stateless session bean(SLSB) but unit testing is a bit awkward to say the least.

I have a SLSB that uses JMS to send messages and have several other methods in the bean. I wrote a quick Messgedriven bean to call the SLSB when i simply drop a text message onto a queue that the MDB is listening to and it also works great but this seems so overkill and I want to write a Junit to test my SLSB methods. The lookup continues to fail even though I call it exactly the same.

must I have to use mock ejb or something else besides a simple Junit?

has anyone ran into this issue? pleas help

thanks

[Lasse Koskela]

David, the solution to this kind of problems is often to isolate the trouble and cut it loose.

In your case, try extracting the way your SLSB is getting hold of the JMS queue/topic into a protected method. Then, in your unit test override that specific method.

In other words, if this is what you have now:

public class SLSB {
    public void businessMethod() {
        doSomeStuff();
 
        // send JMS message
        Context ctx = new InitialContext();
        Queue queue = (Queue) ctx.lookup("jms/MyQueue");
        ...
 
        doSomeMoreStuff();
    }
}

Convert it to something like this:

public class SLSB {
 
    protected Queue lookupQueue() {
        Context ctx = new InitialContext();
        return (Queue) ctx.lookup("jms/MyQueue");
    }
 
    public void businessMethod() {
        doSomeStuff();
        Queue
 
        // send JMS message
        Queue queue = lookupQueue();
        ...
 
        doSomeMoreStuff();
    }
}

The advantage now is that we can bypass the JNDI lookup in our test:

public class SLSBTest extends TestCase {
 
    public void testSessionBeanWithoutRealJmsQueue() throws Exception {
        SLSB bean = new SLSB() {
            protected Queue lookupQueue() {
                return new FakeQueue();
            }
        };
        bean.businessMethod();
        ...
    }
}

Now, we can write a simple FakeQueue class that implements the proper JMS interface but doesn't really do anything.

[Reid M. Pinchback]

There are a couple of variations on Lasse's idea that you can try, depending on the issues you are trying to deal with during testing.

1. If you don't want to create a mock implementation class or use one of the assorted tools that creates one for you, EasyMock can come in handy. Best for situations where you have an interface-based API to implement. It is a little indirect and can take a bit of getting used to, but nice for situations where you want methods to respond with different values based on arguments or how often you invoked the various methods, and you can optionally use it to verify that the implemented methods were actually used.

2. Instead of abstracting objects with big APIs into helper methods, you can create an abstraction based on returning purpose-specific values. For example, instead of a method returning a Queue you can return the string/map/etc. value you expected to get from a message obtained from a queue. Instead of your test class overriding to provide a mock implementation, it overrides to provide a more direct value. The "live" implementation does the usual work of having a connection factory establish a session and a message listener. Both the coarse-grained and the fine grained-approaches are workable, just depends on the specifics of what you are trying to do.