The current stable release is 1.10, available for download at sourceforge.net.

Changes since 1.9:

• HTML output page refresh rate config (contributed by Aaron Smith)
• Bug 952450 fixed (Not serializable objects in session)
• Bug 938685 fixed (formatter displays first test result only)

Dante could never have painted a more fearsome hell than the last few months of a large software project which did not make extensive use of unit testing. There are few creatures more feral and dangerous than a stressed, sleep-deprived, overly-caffinated programmer who has just been told that a bug they fixed two months ago has resurfaced... for the third time.

I've been there. More than once. I'm not going back.

If you're not already a unit testing zealot, you should go immediately to the JUnit home page and read the article Test Infected. That first paragraph is about me. If you haven't heard of JUnit before, it's probably about you, too. Then come back here and find out how to integrate JUnit with J2EE development.

If you have tried to use JUnit with a J2EE application, you probably noticed that the people who wrote JUnit (whom we thank greatly anyways!) have a certain, shall we say, "bias" towards client-side applications. JUnit comes with three TestRunners: an AWT app, a Swing app, and a text-based command-line app. Neither are they suitable for running in an app-server environment nor do they output the HTML we crave.

There is no reason why you cannot use the standard TestRunners if you write your tests as external clients to your app server. But I can think of three good reasons why this is undesirable:

• It is necessary to set up all the client JNDI properties in the test cases, making it a pain to run against several different test servers. Also, if you're like me, you never have bothered to learn how to set up a standalone client. :-)
• If your production clients are servlets running inside the app server, your tests could be affected by being run in a different execution environment.
• It is not possible to unit test your non-EJB web-application components.

Wouldn't you rather run your tests from a servlet?

JUnitEE provides a TestRunner which outputs HTML and a servlet which can be used as an entry point to your test cases. Building your test harness as a standard J2EE web application means:

• Your tests are packaged conveniently into a .war file which can easily be moved between servers; you can leave the .war file in the main .ear file and simply avoid enabling the test web application on the production server.
• Your test classes will be dynamically reloaded by the app server (assuming your server supports this).
• Your test cases look just like your production code, and can use the same beans (or whatever) you use as a facade for your EJBs.

Project services provides by