Java Unit

JavaUnit (Would be called JUnit, but that name doesn't work as a WikiLink) is a RegressionTesting utility for use with the JavaLanguage. It was written by ErichGamma and KentBeck on their way to OOPSLA97 (OopslaHistory). Intended for WhiteBoxTesting by the developer, by implementing regression tests in code. These UnitTests are called by JUnit.

JUnit is just one of the TestingFrameworks known collectively as XUnit, which can be found at http://www.xprogramming.com/software.htm.

JUnit's homepage is http://www.junit.org. JUnit is hosted on SourceForge at http://sourceforge.net/projects/junit/.

JUnit has won reader's choice awards in 2001 from JavaDevelopersJournal and JavaWorld.

Did I mention they wrote it on a plane? I hope they didn't do this during take off or landing, unless the pilot & copilot had already refactored their flight plan!

junit.runner.BaseTestRunner was born live on stage in Sardinia during XP2000.

I assert that JavaUnitIsEvil!

JunitWithIdes

EnhancingJunit Articles and papers Mailing lists Testing pages Me Too

Some other tools in this space: ("Also rans" ;-)

I've just started using JavaUnit, and I ran across a problem with a test that used threads. Basically, I had a reader and a writer thread, both created using inner classes, that accessed an instance variable. The instance variable with initialized and cleared using the setUp and tearDown methods. The problem arose when tearDown was called before the threads had finished executing, which occurred because the methods enclosing the inner classes exited. To get around the problem, I created three objects: 

 Object lock = new Object();
 boolean finished = false();
 boolean success = false();
The reader thread (which determined the success or failure of the test) synchronized on the lock, as did the enclosing method. The enclosing method wait()ed till finished was true and then assert()ed success. Success.

Since this sort of thing will be common for anyone testing a threaded application, I think Assert should include new member variables lock, finished, and success as above (or at least lock and finished - assert() can change the value of finished), and synchronise on lock till finished is true.

Suggestions or comments?

Since most tests don't need this capability, it doesn't seem to belong in Assert. Where else could you put it? SynchronizedTestCase? (a new class)?

(Make sure you see ExtremeProgrammingChallengeFourteen if you're unit testing concurrent code.)

I've written a CollectingTestSuite? class that finds all the test classes in the class-path, and organizes them into a tree of suites, one per package. This reduces the time to write a test even further - no need to write suite() methods or write per-package test-suite classes. If anyone is interested in getting a copy or including it in the JUnit distribution, please get in touch. -- NatPryce

Why not take a look at http://www.javaworld.com/javaworld/jw-12-2000/jw-1221-junit.html (get the source code ZIP) and see if a better CollectingTestSuite? can result from a merge of the two codebases.

Why not use Ant's batch test?

A new problem with JUnit comes with the pre-releases of JDK1.4, where "assert" is now a keyword, hence not available as a name for a method. Happily, JUnit comes with modifiable source code, so I can change the names, but it would be nice for a future JUnit to work with the latest Sun JDK. -- JamesDennett

To expand: From how I understood the documentation, JUnit should still work with JDK1.4 in the default mode, in which "assert" is not treated as a keyword (haven't tested though). If you want to use the new assert feature, you explicitly have to set a compiler option, and only in this case would JUnit break. In future versions of the JDK, the latter will become the default (or only?) setting. -- FalkBruegmann

3.7 introduces assertTrue(boolean) and deprecates assert(boolean) in preparation for JDK1.4. When it's closer we'll use the native AssertionException?. We're reluctant to move too quickly because we are still basically JDK independent and we would like to maintain this as long as possible. -- KentBeck

How about adding an assertFalse(boolean) for symmetry? -- BrettNeumeier

It will be there in 3.8, expected release date October 2001. -- KentBeck

I've been having a problem with using tearDown ... basically, I put test code in tearDown that goes off any time anything else in the test code stops it. But the problem I'm having is that when one of the tests throws an exception, and then the tearDown code throws an exception, too, JUnit seems to report the exception thrown in tearDown, which is less specific and less helpful.

Maybe the best way to solve this would be for TestCase to have some sort of a method like 

 public boolean exceptionCaught
that you could check if you're running test code in your tearDown. (I suppose I could just download the JavaUnit code and add this myself. Item 422 on the to-do list ...)

... Thinking about it later, maybe test code shouldn't be tearDown at all -- it seems like its original purpose, as with setUp, is to deal with external resources that the tests need in order to run. My usage of tearDown could properly by considered a hack, I suppose. Makes me think that perhaps it would be nice to have a finalTest function to override or something like that. I wouldn't be the only person who'd find this useful, would I?

See also: HelpWithJavaUnitProblems

CategoryTesting CategoryJava TestingFramework

EditText of this page (last edited September 18, 2010) or FindPage with title or text search