permaculture playing cards
The moose likes Testing and the fly likes Junit testing on a stateless session bean Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Testing
Bookmark "Junit testing on a stateless session bean" Watch "Junit testing on a stateless session bean" New topic

Junit testing on a stateless session bean

david lightman
Ranch Hand

Joined: Nov 03, 2004
Posts: 82
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

Lasse Koskela

Joined: Jan 23, 2002
Posts: 11962
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:

Convert it to something like this:

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

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

Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Reid M. Pinchback
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
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.

Reid - SCJP2 (April 2002)
I agree. Here's the link:
subject: Junit testing on a stateless session bean
jQuery in Action, 3rd edition