In this article, the first in a 3 part series on Container Driven Testing, N. Alex Rupp shows you how to test your beans directly inside the EJB Container. Container driven testing lets you write more isolated, fine-grained and robust unit tests. Using code samples, he discusses how to use OpenEJB's container driven testing features to simplify and 'supercharge' your EJB testing.

Read Container Driven Testing: Advanced EJB Testing with OpenEJB - Part 1: Testing Inside the Container

"Testing EJBs in a fake container is like trying to test java objects in a fake VM." —David Blevins, OpenEJB.

And <paus> OpenEJB is a real container? Both of you using it: raise your hands!

Both of you using it: raise your hands!

:)

You might be surprised how many people *are* using OpenEJB. It's the default servlet container in Apache Geronimo, for example. And regardless of whether or not you use it as your production container, you can still use it for purposes of testing your component functionality.

As I understand it, there's been a lot of interest lately in making EJBs more testable. OpenEJB makes the process relatively painless. It's spec compliant and available under a royalty-free license. If there's any legitimate gripe that can be made about OpenEJB, it's that David Blevins should have marketed its testing functionality years ago. I say "better late than never".

I hope you can take the time to consider the possibilities. It really is a neat and useful technology.

Cheers,
--
Alex

It's the default servlet container in Apache Geronimo

Whoops--mixing articles here. Make that "default EJB container" :P

--
Alex

All the EJB testing philosophies out there involve building up an elaborate but ultimately fake environment within which to test your beans, separating you and your tests from EJB and the Container

i guess i'm not that familiar as i could be with EJB testing philosophies. i use and advocate cactus testing to verify the business logic that is required of a stateless session bean (session facade providing a business operation such as "postOrder()" or some such). this is testing the beans in a live running container. the tests take longer to get feedback than a simple junit test, but IMO is the biggest bang for your buck in terms of test code coverage. when your sls bean wires together 4-5 other sls beans to do its work, and combines business "rules" from all those other beans, you've got to make sure the operation as a whole is working as prescribed.

can OpenEJB provide me with things like a Database connection from JNDI? it _may_ be nice to mock up the database, but really, it's much easier to just connect to the live db and run the beans against it.

i like the tip about getting the IC during the constructor as oppose to the setup method. i wonder it this will help out my cactus testing?

this is testing the beans in a live running container. the tests take longer to get feedback than a simple junit test, but IMO is the biggest bang for your buck in terms of test code coverage.

I completely agree. It's tough to test Servlets, which is why I like getting through the servlet and into a dependency injection framework as soon as possible. I was surprised when I first learned how easy it was to test EJBs, so my new strategies are to get through the servlet layer as fast as possible and do as much work in the EJB tier as I can. And like you said, from a code coverage stance, this strategy is definitely king.

when your sls bean wires together 4-5 other sls beans to do its work, and combines business "rules" from all those other beans, you've got to make sure the operation as a whole is working as prescribed.

I'd shy away from calling those "rules". One of the principles of business rules is that rules are removed from components in the system and kept in a place, usually a central repository of some kind where they can be easily managed. Sorry--rules are something of a sacred cow to me :)

can OpenEJB provide me with things like a Database connection from JNDI? it _may_ be nice to mock up the database, but really, it's much easier to just connect to the live db and run the beans against it.

Absolutely--I'll introduce you to this in Part II, which I'm told will be published in two weeks. If you're running in full server mode, you can even test remoting--that article will come out in four weeks :)

i like the tip about getting the IC during the constructor as oppose to the setup method. i wonder it this will help out my cactus testing?

I try not to overuse my setUp and tearDown methods. Anything that doesn't need to get scraped for each test method I put into my constructor method. Now if tests had a real lifecycle with a guaranteed deconstructor, we'd really be in business. We could, for instance, reset the contents of the DB so it didn't b0rk our other test cases.

"Testing EJBs in a fake container is like trying to test java objects in a fake VM." —David Blevins, OpenEJB.And <paus> OpenEJB is a real container? Both of you using it: raise your hands!

By both I assume you mean Apple's WebObjects and Apache Geronimo? OpenEJB is an embeddable, BSD licensed, EJB implementation--a lot of people are using it and don't even know it.

Many of the testing features were created exactly because of it getting integrated into various things. When we were working with Apple on WebObjects integration, they require an extremely high percentage of code coverage before (tests that exercise your code, for those who aren't familiar). It became clear we needed to test the container isolated and then test it again once integrated. Because we needed to test it against two distinctly different "front ends", or servers as we call them, we weren't able to write the tests in a way that was tied to OpenEJB. That was the catalyst for engineering a testing approach that allowed you to test against the container, but do it in a way that didn't tie you to the container. The result is just a plain old ejb test (POET?) interacting in a standards compliant way, but with some clever integration glue driving the whole thing.
Anyway, the types of users that OpenEJB gets are the exact reason for it's quality and unique features. OpenEJB doesn't just target application developers, but software developers that are looking to add EJB support to their projects/products in some way or another.

The result is just a plain old ejb test (POET?)

LOL! Now there's a sweet acronym. Someone point Dick Gabriel at this--I'm sure he'd appreciate it at least as much as I do :)

--
Alex (whose degree is in poetry)

cool! Can I use, for unit tests, a JCA adaptor inside the OpenEJB ?

cool! Can I use, for unit tests, a JCA adaptor inside the OpenEJB ?

You can, but you'll need to run the full EJB server instead of just the EJB container. I cover how to do that in Part III of the series, which should be out in four weeks or so :)

HTH
--
Alex

cool! Can I use, for unit tests, a JCA adaptor inside the OpenEJB ?

Yes. OpenEJB supports any J2CA 1.0 connector or connection manager. This works regardless of using OpenEJB embedded or standalone.

Does OpenEJB support EJB 2.0 beans? If not, when is the expected date?

Thanks

Does OpenEJB support EJB 2.0 beans? If not, when is the expected date?

I'm not an OpenEJB developer, but I do cover this question in Part III of the article, which I'm told will be published in July. I can tell you that the OpenEJB 2.0 code is quite well along, and that it provides all the same testing capabilities. If I had to make a guess, I'd wager sometime in late summer or early autumn.

Hop on the #openejb channel at irc.codehaus.org, and ask the developers what they think. :)

--
Alex

The example does not work with OpenEJB-2.0-SNAPSHOT at the moment.

I got the 2.0 snapshot by downloading the latest CVS source then modified the project.xml to refer to the 2.0 snapshot jar instead of the 1.0. Got a NullPointerException. Hopefully its because its just an error in the snapshot and not the example.

EJB 2.1 support is already underway. All this work is being done in the OpenEJB 2.0 code line. Geronimo 1.0 M1 was just released which uses the latest OpenEJB 2.0 code for EJB 2.1 support, so that should give you some idea of how close we are. We should be finished sometime late summer and J2EE certified whenever Geronimo gets certified.

Where can I get my hands on OpenEJB 2.0, even if it's not ready for production use yet? The only download links I can find on the OpenEJB site are for 0.9.2, which is apparently compliant with version 1.1 of the spec.

Any support for Hibernate in OpenEJB?

Any support for Hibernate in OpenEJB?

What a strange question. In what ways do other EJB container "support Hibernate"? I fail to see connection.

Any support for Hibernate in OpenEJB?

What a strange question. In what ways do other EJB container "support Hibernate"? I fail to see connection.

I think what he was really getting at with his question was whether or not you could do Container Driven Testing with Hibernate. Trouble is, I have no idea--if you've eschewed the EJB standard, you need to talk with the Hibernate team about this--I'm sure if there's a demand for it they'll happily build it into their system. They're a great bunch of guys.

That's a risk you take when you decide to use a non-standard technology like Hibernate. The rest of the industry might pass you up. Open Standards like J2EE make it easier for multiple vendors to supply technology for the problem space. The community-based process definitely leads to innovations like what OpenEJB's brought us.

One nice thing about Hibernate is that Mr. King's been such an active part of the Open Source community and that, by making usability a policy issue, his work has had such an impact that the other vendors are listening to his ideas. I really have to commend him on that. I've been a fan of his work since the Ward Mullins days ;)

The question I can't shake, however, is whether or not in the decades some of the industry experts have been working in the CTM problem space they've run into challenges that the Hibernate developers and users aren't aware of. I have a hunch that the future of Hibernate will look more like EJB than the future of EJB will look like Hibernate, and that instead of avoiding having to write complex EJB systems we should instead focus on building better tools and Domain Specific Languages to generate EJB component subsystems. Well-architected EJB Containers and Servers will play a major role in making this possible.

In the end, I wouldn't say Hibernate users are completely out on their own like some sort of lost colony. Quite the contrary. Hibernate isn't an abandonment of EJB--Hibernate is a conversation with EJB. Look for more convergence between the two down the road.

Cheers,
--
Alex

"The question I can't shake, however, is whether or not in the decades some of the industry experts have been working in the CTM problem space they've run into challenges that the Hibernate developers and users aren't aware of"


I think its unlikely at this juncture that there are fundamental problem with business operation level transactions that have not already been unearthed by existing RDMS and OODBMS systems.

Paul C.

I think its unlikely at this juncture that there are fundamental problem with business operation level transactions that have not already been unearthed by existing RDMS and OODBMS systems. Paul C.

Paul, I agree with you completely on that. I wasn't implying that there were new issues springing up that Hibernate hadn't caught on to yet. I was suggesting that there are well-known issues that don't really come into play unless you're running a large-scale operation, and that Hibernate doesn't adequately address them yet.

I don't think I'm unreasonable in saying this, and I'm sure you're not implying that Hibernate is the perfect brush for every painting style. Most people would agree it isn't, and EJB isn't either. I think each side can learn from the other, and I'm a big fan both of EJB's robust capabilities and Hibernate's attention to pragmatics.

In JBoss, you can host an MBean that loads the hibernate configuration of all your POJO objects, and your SessionBean can obtain an Hibernate Session from that MBean via JNDI.
Witch this config, you can use SessionBean + POJO + Hibernate for persistence.
I was wondering if such mecanism was available in OpenEJB.

Any support for Hibernate in OpenEJB?

No, there is no Hibernate support in the OpenEJB container. This is because OpenEJB addresses a very specific problem domain defined by the EJB spec. Hibernate, on the other hand, doesn't implement the EJB spec (by design). It's doing its own thing, experimenting with different approaches. I'm certain that the Hibernate team could provide similar functionality if they haven't already :)

The nice thing about the OpenEJB approach is that you don't tie yourself to their implementation details at all. I really appreciate the thought that was put into that, because even if I'd built my beans to run on Websphere, I could use this Open Source tool to test them. That'd be my reward for sticking to Open Standards :)

I *have* heard rumours of a pseudo-secret Open Source project that can convert hibernate objects to EJBs, XML, etc. Can't say anything definitive, though.

;)
--
Alex

All the EJB testing philosophies out there involve building up an elaborate but ultimately fake environment within which to test your beans, separating you and your tests from EJB and the Container

i guess i'm not that familiar as i could be with EJB testing philosophies. i use and advocate cactus testing to verify the business logic that is required of a stateless session bean (session facade providing a business operation such as "postOrder()" or some such). this is testing the beans in a live running container. the tests take longer to get feedback than a simple junit test, but IMO is the biggest bang for your buck in terms of test code coverage.

That speed would be greatly increased using OpenEJB embedded in cactus.

can OpenEJB provide me with things like a Database connection from JNDI?

Absolutely. It's a full-blown EJB Container, just design to be able to scale down as well as up. It can use any J2CA 1.0 connector and includes a connector that wraps JDBC drivers so they can be connectors too.

it _may_ be nice to mock up the database, but really, it's much easier to just connect to the live db and run the beans against it.i wonder it this will help out my cactus testing?

My preference is to export a snapshot of the actual database into a SQL script and use it as the test data. I'll usually modify it a bit, but it keeps things realistic and reflects the actual production data. I then use an embedded database like hypersonic, InstantDB (dead, but still works), or Axion. I create all the tables at the beginning of the testing and drop them all afterwards.

YMMV, but that is one approach that's worked faithfully for a number of years.

i wonder it this will help out my cactus testing?

Vincent Massol (sp?) is working on integrating OpenEJB into Cactus, so it will definitely help. It could be done now, but he wants to find a way to alleviate the need for an openejb.conf file. If that doesn't bother you, than you're good to go--you can use OpenEJB in Cactus now as there really isn't any setup required in your code. It all just happens automagically.

Hmm. This post should have gone in reply to the Cactus thread. Oh well :)

IMO this is the way to go. Completely separating your "Application" concern from your "Infrastructure" concern (just the good old separation of concerns concept). I as an application developer just write my application (in this case, my test) towards the standardized APIs. How my application or test will be run (inside, outside) the container is not my problem.

I use a trick to do the same thing in JOnAS by running the test client as a JOnAS "service". So at the end I just need to run my JOnAS server (no need to run the test client seperately), which in turn will start my application/test automatically. Very simple.

Greets,
Lofi.

Hello.

Maybe I didn't understand the concept, but what conclusions can you derive from successfull Unit tests using the OpenEJB container? It should also work using a J2EE compliant App-Server ...? From my point of view you still need to test against your _real_ environment, otherwise you'll never be shure if it works.

Regards,
    Dirk

Hello.Maybe I didn't understand the concept, but what conclusions can you derive from successfull Unit tests using the OpenEJB container? It should also work using a J2EE compliant App-Server ...? From my point of view you still need to test against your _real_ environment, otherwise you'll never be shure if it works.Regards, Dirk

Dirk, I think you're right. People should be able to test against their production environment. That's one more reason I'll be using Geronimo as my production server once it passes the TCK. I'll be able to run Plain Old EJB Tests against the same EJB server used in my production environment, it'll be easy to set up, fast and it all comes with a BSD-like (non-GPL) license. I briefly mention this in part III of the series.

The other big vendors out there should be able to take a page from OpenEJB's book and more cleanly separate the concerns of their Container and the Server implementations. There's nothing preventing them from doing it, except perhaps an indication from their customers that EJB Testing functionality is worth paying for. The OpenEJB strategy makes Plain Old EJB Testing easier to accomplish, it makes the container more embeddable and in my mind it's just plain cool.

OpenEJB's developers took the time to architect their system to make it embeddable and to make it easier for people to test their components. The payoff is that it helps us write better EJB code. The other app servers out there didn't take the time to sweat these details, and people have been quite bitter about the results. I think the OpenEJB guys deserve some distinction and some recognition for their hard work and forsight. And I think that developers deserve to know they've got another powerful option for unit testing their component systems. That's really what these articles are about.

Best,
--
Alex

For those of you who are still referring to this article; the example code which is referred to is now located: http://openejb.codehaus.org/ejb-testing-examples-part01.zip ... etc. Cheers.

For those of you who are still referring to this article; the example code which is referred to is now located:

http://openejb.codehaus.org/ejb-testing-examples-part01.zip

... etc.

Cheers.

The following changes are required in the project.xml for the example to work:

geronimo-spec geronimo-spec-j2ee 1.4-rc3 <!-- changed from rc1 --> openejb openejb-core 1.0 <!-- changed from 1.0-SNAPSHOT -->

Would like to use the latest openejb release for this framework, any inputs are welcome. Gagan Bhatnagar

An official apology to OpenEJB users for OpenEJB 2.0 which was only useable in Geronimo. OpenEJB 2.0 is officially deprecated and now even Geronimo is using OpenEJB 3.0. OpenEJB 3.0 pics up where OpenEJB 1.0 left off and adds support for all EJB applications up to and including EJB 3.0. Embedded, standalone, and Tomcat modes all work. Additionally, improvements in the embedded capabilities have eliminated the need for an openejb.conf file. We hope N. Alex Rupp will have an updated version of this great series available, but in the mean time examples of embedded testing with OpenEJB 3.0 and EJB 3.0 are available here: http://openejb.apache.org/examples.html http://openejb.apache.org/calculator-session-stateless-bean-example.html http://openejb.apache.org/ejb-injection-example.html http://openejb.apache.org/resource-injection.html The embedded testing support extends to EJB 1.1, 2.x, and EJB 3.0 applications, so anyone previously using embedded testing with OpenEJB 1.0 and EJB 1.1 could upgrade to OpenEJB 3.0. The final version of OpenEJB 3.0 is due to come out in the next couple weeks, I'll update this thread when that drops.