| ||||||||||||||||||||||||||||||||||||||||
|
The current stable release is 1.10, available for download at sourceforge.net. Changes since 1.9:
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:
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:
|