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 UnitTest''''''s 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.BaseTestR''''''unner was born live on stage in Sardinia during XP2000. I assert that JavaUnitIsEvil! ----- '''JunitWithIdes''' * JunitWithForte - It's easy to use JUnit with Sun's ForteForJava. * JunitWithNetBeans - There's a very good JUnit Module for NetBeans (built around JUnit 3.5). Supports generating test stubs from public functions, managing test suites, and running unit tests within the IDE (including compilation detection). * JunitWithKawa - You can run JUnit tests from the KawaIde. * JunitWithMicrosoftTools - There are some problems using JUnit with Microsoft's SDK 2.01 (implements JDK 1.1.4). * JunitWithJbuilder - You can run JUnit tests from BorlandJbuilder. * JunitWithVisualAge - Basic support for VisualAge is including in JUnit distribution. See link for gotchas and thoughts. * JunitWithEclipse - ErichGamma has written an Eclipse plugin to run JUnit tests. * JunitWithIdea - IntellijIdea (that also has Refactoring support) can run JUnit tests. '''EnhancingJunit''' * Abbot - http://abbot.sf.net - Unit test UI components (JavaAwt and JavaSwt), functional/acceptance tests for applications * EjbUnitTest - Comment that JUnit has been used to test EnterpriseJavaBeans. * HttpUnit - Works with JUnit to allow automated testing of web applications http://httpunit.sourceforge.net/ * HtmlUnit - alternative to HttpUnit that more closely models HTML, rather than HTTP. Similar purpose as JwebUnit. http://htmlunit.sf.net/ * ParallelJUnit - Run JUnit tests in parallel - http://parallel-junit.dev.java.net/ * ServletUnit - Is a ServletTesting test harness to allow JUnit to drive servlets. * JavaUnitAndAnt - Run JUnit from ApacheAnt. * JunitEe * JakartaCactus - Extends JUnit for testing server-side java code (recommended). * JUnitPerf - JUnit test decorators for performance and scalability testing (http://www.clarkware.com/software/JUnitPerf.html) * JunitServlet - Servlet TestRunner for testing from the inside of an app server (now retired, replaced by JakartaCactus) * JUnit++ - load testing http://www.geekfarm.org/emeade/junit/junit++.zip * JUnitX - test private methods (jdk1.3) http://www.extreme-java.de/ * JunitCreator - A tool for VisualAge Java that automatically creates JavaUnit test case templates. * JunitFiles - http://groups.yahoo.com/group/junit/files/ - odds and ends. * JFCUnit - http://sourceforge.net/projects/jfcunit - testing Swing GUI * JwebUnit - Works with HttpUnit to provide a friendlier interface abstracted way from HTTP. Similar purpose as HtmlUnit. * NoUnit - Shows what code is covered by your JUnit tests. * StrutsTestCase - a JUnit extension for handling Struts-based classes - http://strutstestcase.sourceforge.net/ * TestCollector - A must-have for the serious testing connoisseur. * TagUnit - framework for testing JSP custom tags (okay, so it doesn't actually extend JUnit :-) ) * WebUI for JUnit - JUnit UI framework allows running your unit tests through web browser. Web UI looks similar to common JUnit frameworks running on a local computer. http://www.softxp.com/webui/ * XmlUnit - test classes for assertions about XML * JUnitDoclet - incremental generation of tests+suites from sources; configurable template; http://www.junitdoclet.org/ '''Articles and papers''' * http://members.pingnet.ch/gamma/junit.htm * MartinFowlersJunitPaper * JUnit: A Cook's Tour appeared in JavaReport, May 1999: http://www.junit.org/junit/doc/cookstour/cookstour.htm. See also JunitCooksTour * There is an interesting article at JavaWorld on enhancing JUnit to test EJBs called "Test Infect your Enterprise JavaBeans." See: http://www.javaworld.com/javaworld/jw-05-2000/jw-0526-testinfect.html and JunitServlet * JGuru has a page on JUnit http://www.jguru.com/faq/JUnit * Incremental development with Ant and JUnit: http://www-4.ibm.com/software/developer/library/j-ant/?dwzone=java * The Test/Code Cycle in XP: Part 1, Model: http://www.xp123.com/xplor/xp0002/ * The Test/Code Cycle in XP: Part 2, GUI: http://www.xp123.com/xplor/xp0001/ * Is Design Dead?: http://www.martinfowler.com/articles/designDead.html * A UML Testing Framework: http://www.sdmagazine.com/articles/1999/9904/9904c/9904c.htm * JUnit Primer: http://www.clarkware.com/articles/JUnitPrimer.html * Xtreme testing: http://community.borland.com/devnews/article/1,1714,10431,00.html * JUnit Best Practices: http://www.javaworld.com/javaworld/jw-12-2000/jw-1221-junit.html * eXtreme Testing: http://www.ociweb.com/javasig/knowledgebase/Oct2000/ * The JUnit++ Testing Tool: http://www.ddj.com/articles/2001/0102/0102toc.htm * Testing WebSphere Applications: http://www7b.boulder.ibm.com/wsdd/library/presents/junit.html * in German: Unit Testing with JUnit: http://www.frankwestphal.de/UnitTestingmitJUnit.html * JUnit Starter's Guide: http://www.diasparsoftware.com/articles/JUnit/jUnitStarterGuide.pdf * Test networked code the easy way: http://www.javaworld.com/javaworld/jw-07-2002/jw-0719-networkunittest.html * Junit tutorials and example: http://www.javarmi.com/2010/09/junit-tutorials-and-example '''Mailing lists''' * http://groups.yahoo.com/group/junit/ * http://groups.yahoo.com/group/junit-functionaltests '''Testing pages''' * TestingPatterns * OrganizingTestCases - Some hints on how to organize you test cases in packages and directories. * TestInfected - The dangers of using JUnit. * UnitTestingJavaEvents - Question regarding UnitTest''''''ing JavaEvents. * ExtremeProgrammingChallengeFourteen - testing concurrent programs. * JavaUnitBestPractices '''Me Too''' * WhoIsUsingJunit - Don't be the last on your block! * WhoIsUsingIntellijIdea - Develop With Pleasure! * WhoIsUsingEclipse - Develop With Pleasure for free! ----- ----- Some other tools in this space: ''("Also rans" ;-)'' * Sun's (no longer available) JavaStar and JavaSpec * ParaSoft's JTest (JavaTest) * open source IDebug framework (IdebugFramework) * JdefendTest = "jDefend: One Configuration File for All Your Test Scenarios" ---- ---- 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 T''''''estCase 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