Testing EJB with Junit

[shawn kennedy]

How do i do ejb testing with junit.Can someone give me an example code to understand

[Lasse Koskela]

You can a) hit with a hammer, or b) go light. Both projects provide sample code.

[Lasse Koskela]

Oh, I forgot to state an opinion...
I think you can go far without testing EJBs at all. You can easily delegate everything into plain old Java objects as follows:

/**
 * You'll never need to test this class as its so plain simple.
 */
class EJB {
    private Delegate delegate;
    public void ejbCreate() {
        this.delegate = new Delegate();
    }
    public String bizMethod() {
        Resource fooResource = obtainFooResource();
        Resource barResource = obtainBarResource();
        return this.delegate.bizMethod(fooResource, barResource);
    }
}
/**
 * This is the class that does the work and it's very easy to 
 * test (for example, using MockObjects).
 */
class Delegate {
    public String bizMethod(Resource foo, Resource bar) {
        // do something with the given resources and return the result
    }
}

[ November 03, 2003: Message edited by: Lasse Koskela ]

[Ilja Preuss]

Yep, the trick for testing things which are hard to test is always the same - make it so dumb that it doesn't need much testing and let easy to test units do the hard work.

[Andres Gonzalez]

Another way to test EJBs is by using Jakarta Cactus

[Jeanne Boyarsky]

Lasse,
What does JunitEE offer over regular JUnit? From the home page of the site you linked to, it looks just like regular JUnit. At work, we test our EJBs using regular JUnit so I'm curious about the difference.
I have a question about Cactus too, but I need a while to formulate it. I guess I'll ask that question tomorrow when the forum is hopping

[Lasse Koskela]

Originally posted by Jeanne Boyarsky:
What does JunitEE offer over regular JUnit? From the home page of the site you linked to, it looks just like regular JUnit. At work, we test our EJBs using regular JUnit so I'm curious about the difference.

Nothing really. It's just that having the regular JUnit tests execute at the server-side make it slightly easier to locate resources (compared to running the unit test as an EJB client in another JVM). And of course, running the unit tests on the server-side and being able to run/display using a web browser could be counted as a small plus.

Originally posted by Jeanne Boyarsky:
I have a question about Cactus too, but I need a while to formulate it. I guess I'll ask that question tomorrow when the forum is hopping

You're more than welcome to do that

[Lasse Koskela]

Oh, there is a Junit add-on called EJBUnit or MockEJB or something which is basically a mock-up of an EJB container. I haven't used it myself so I can't say whether it's any good.

[Burk Hufnagel]

I assume you mean testing of session beans (seems odd to test an entity, since all it does is store data) and I've found that Cactus can be difficult to use - even with a tool like the wizard in JBuilder. As long as your bean has a remote interface, you can just use JUnit. Get the remote and test away.
If the bean doesn't have a remote interface then you can still create a pass-through session bean - has a remote interface that matches the bean to be tested and just passes calls to the bean to be tested and returns whatever the result is. From that point, follow the directions above.
Of course, putting a testing bean in the middle means that you have to verify where the error is when a test fails. But that's one of the trade-offs. All I can tell you is that it works.

[Vincent Massol]

Originally posted by Lasse Koskela:
You can a) hit with a hammer, or b) go light. Both projects provide sample code.

Yep! But this not what I call light! Light would be using Mock Objects for me :-). Chapter 12 of JUnit in Action details how to unit test EJBs both with Cactus and with mock objects. Of course, you could also not test them but that would require a different architecture. If you're already using EJBs calling EJBs, etc, it may prove to hard to change your architecture. In any case, even if you delegate to POJO objects, you'll need to test the integration with the container at some point in time (for distribution, persistence, JNDI access, transaction, etc). This can be done using functional tests or integration tests (a la Cactus).
BTW, I'm not sure in what regards J2EEUnit can be considered "lighter" than Cactus? Cactus supports the same features as J2EEUnit AFAIK.
Thanks
-Vincent

[Dimitar Gospodinov]

There is MockEJB. It is very light framework that let you test/run EJBs outside of the container. It is based on JUnit and Cactus (if you want to perform test inside a container).
Have a look at:
MockEJB home page

Regards,
Dimitar

[Lasse Koskela]

Hello Dimitar,
First of all, thanks for the link and welcome to the JavaRanch!
Second, would you mind "adding more characters" into your display name? You know, we have a naming policy, which requires display names to include a last name (initials aren't enough). You can change it here.
Thanks.

[Ilja Preuss]

Originally posted by Burk Hufnagel:
I assume you mean testing of session beans (seems odd to test an entity, since all it does is store data)

Is that really the case? I always thought that entity beans could contain logic, too. But I am far from being an expert in this field...

[Reid M. Pinchback]

Yes, entity beans can have behaviour that needs testing. You can have component interface business methods (EJB 1.1) and home interface business methods (EJB 2.0). Other than that, unit tests would typically only come up in testing things like creation or population of transfer objects (not an EJB issue per se, a J2EE pattern technique).
Practically most entity bean tests, particularly for CMP, are integration tests, not unit tests. You are making sure that your code works with the database and EJB container. You Java code could be perfectly correct, but your deployment descriptor unsuited to a particular deployment environment.