FYI:JUnit 3.8.2, which was released late last year, includes a number of bugfixes and small improvements from the version that is currently officially supported by our test harness, 3.8.1.
The most noticeable improvement is a change to the String comparison format. For example, with JUnit 3.8.1, if we compare two SQLStates that are almost the same, but not quite, JUnit will report something like this (don't mind the actual failure, I simply tweaked the test to make a point):
> There was 1 failure:> 1) testStatementExecuteAfterConnectionClose(org.apache.derbyTesting.functionTests.tests.jdbc4.StatementTest)junit.framework.ComparisonFailure: Unexpected SQL state for performing operations on a closed statement. expected:<...6> but was:<...3>
> FAILURES!!!It is hard to see what the SQLState we actually got was, and further debugging is required.
With JUnit 3.8.2, this is what we'll see instead: > There was 1 failure:> 1) testStatementExecuteAfterConnectionClose(org.apache.derbyTesting.functionTests.tests.jdbc4.StatementTest)junit.framework.ComparisonFailure: Unexpected SQL state for performing operations on a closed statement. expected:<0800[6]> but was:<0800[3]>
> FAILURES!!! The rest of 3.8.2 is , AFAIK, compatible with 3.8.1. JUnit 3.8.2 can be downloaded from http://sourceforge.net/project/showfiles.php?group_id=15278 (scroll down past the 4.1 release).I'm attaching the changelog, since I downloaded it some months ago and I am not able to find it online any longer.
Try it out if you want. Perhaps we should start recommending JUnit 3.8.2 instead of 3.8.1?
-- John Knut Anders Hatlen (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1417?page=comments#action_12430163 ] Knut Anders Hatlen commented on DERBY-1417:------------------------------------------- Hi Kristian, I tried to run derbyall with the 8a patch and the patch for DERBY-1473. I see this error: *** End: TestQueryObject jdk1.6.0-rc jdbc40:jdbc40 2006-08-24 00:50:02 *** ********* Diff file jdbc40/jdbc40/PreparedStatementTest.diff *** Start: PreparedStatementTest jdk1.6.0-rc jdbc40:jdbc40 2006-08-24 00:51:29 *** 0 add................................F......... There was 1 failure: 1) testSetBinaryStreamLengthLessOnBlobTooLong(org.apache.derbyTesting.functionTests.tests.jdbc4.PreparedStatementTest)junit.framework.ComparisonFailure: Unexpected SQL state. expected:<...CL30> but was:<...SDA4> FAILURES!!! Tests run: 82, Failures: 1, Errors: 0Test Failed. *** End: PreparedStatementTest jdk1.6.0-rc jdbc40:jdbc40 2006-08-24 00:51:34 ***
Title: JUnit 3.8
JUnit 3.8.2
11/11/2004
Summary of Changes between 3.8.1 and 3.8.2
The changes between the versions are minimal and the focus was on fixing the accumulated bug reports. The most signifanct change is replacing the much-reviled string comparison format with something easier to read and use.- ComparisonFailure shows context.
- assertEquals("Mary had a little lamb", "Mary had the little lamb") shows: expected:<Mary had [a] little lamb> but was:<Mary had [the] little lamb>
Longer prefixes and suffixes are truncated to a fixed size (currently 20): - expected:<...st of the emergency [broadcasting] system> but was:<...st of the emergency [locating] system>
- Running single tests. junit.ui.TestRunner can be invoked with "-m ClassName.testName" to run a single test.
- TestSuite(Class[]). There is a new TestSuite constructor that takes an array of classes as a parameter and returns a suite of suites, each of which is constructed from a single class.
Closed Bugs/Patches and Enhancment Requests
- assertEquals(float,float,delta) fails on negative delta
- '...' in ComparisonFailure
- Trouble in teardown hides orig. probl.
- NaN's in assertEquals
- BaseTestRunner.setPreference static
- failNotEquals() should be protected
- RFE: make private methods protected
- Printing version number
- Patch to quell warnings in tiger
- Enhanced ComparisonFailure output
- addt'l TestSuite constructrs for Class[]
- Run one test method for junit
- excluded.properties: Add commons logging
Summary of Changes between 3.8 and 3.8.1
- Backed out setting the testing Thread's context class loader (see JUnit not setting ClassLoader). It has caused problems in tests that worked OK before. See the bug report for more details.
- Fixes:
Summary of Changes between 3.7 and 3.8
Framework
- Made the string argument TestCase constructor optional. You can now delete constructors of the form "FooTestCase(String name) { super(name); }".
- Deleted deprecated assert(boolean) in favor of assertTrue(boolean) and assertFalse(boolean). To migrate to JUnit 3.8, rename calls to assert(boolean) to call assertTrue(boolean).
- Added assertFalse() to avoid the difficult of reading the assertTrue(! condition).
- Added assertNotSame(Object, Object).
- Deleted deprecated TestCase.name() in favor of TestCase.getName().
- Deleted deprecated package junit.ui in favor of junit.awtui.
Test Runner
- When you compare two long strings with a small delta embedded in the middle, it is hard to spot the difference. In 3.8, when you call assertEquals(String, String), only the differences between the strings are displayed. The common prefix and suffix are replaced with "...".
- Added initial version of a TestRunListener attached to TestRunners which eventually will replace TestListeners attached to the TestResult.
- Filled in ActiveTestSuite constructors.
- Added these packages to the excluded.properties:
- org.w3c.dom.*
- org.xml.sax.*
- net.jini.*
- Extracted textual formatting of a TestResult from junit.textui.TestRunner into ResultPrinter.
Documentation
- Much improved FAQ thanks to Mike Clark.
Closed Bugs
- Class loader problem
- Cookbook Simple Test Case problems
- License not included in source
- assert is a keyword
- javadoc returns mysterious message
- swingui CounterPanel values disappear
- TestCase javadoc incorrect example
- silly cookbook error
- junit properties missfunction
- Test.java is not Serializable
- JUnit not setting ClassLoader`
- NullPointerException when loading suite
- labels for bug counts too small in Swing
- Swing TestRunner layout shifts
- Exit code problem for cygwin/w2k
- Automatic reload causes strange errors
- TestRunner fails with swing/awtui
- CVS version doesn't build on NetBSD
- NullPointerException JUnit sample w/ Ant
- money sample bug
- incomplete message from failNotSame()
- Icons on systems with 64 colors exceptio
- 1000+ tests, swing gui doesn't display
- test selector included incorrect classes
- No UI update when re-run methods fail
Summary of Changes between 3.6 and 3.7
GUI
- Eliminated warning when re-running tests when class loading checkbox is unchecked. There are legitimate reasons for doing this, so a warning didn't make much sense, and it was too obtrusive.
- Stopped reloading classes when running in VisualAge for Java.
- Print total number of tests as well as number of tests run so far (Swing only).
Framework
- Introduced Assert.assertTrue(boolean) and assertTrue(String, boolean) deprecated assert(boolean) and assert(String, boolean) in preparation for the assert keyword in Java 1.4. We plan to support native assertions when they are publicly available. You can either move to assertTrue() or wait for 1.4 and delete parentheses as the syntax is e.g. "assert 2 == 3".
- Added accessors for TestCase.fName and TestSuite.fName.
- Added a no argument TestCase constructor to support serialization.
- Improved warnings when constructing TestSuites.
Text Runner
- Made doRun() public so clients can create a text runner with a specified output stream and then run tests.
Fixed Bugs (SourceForge Bug Tracker Ids)
[420315] No trace when fail with message...[419375] reload warning lags
[418849] Classloader warning too obtrusive
[417978] constructor stack trace, please
[415103] Reload checkbox should be ignored in VAJ
[414954] error reporting when invoking suite()
[407296] Make doRun() public
[227578] rmi callbacks fail since TestCase has no noArg constructor
[422603] Decorated decorators bug
Summary of Changes between 3.5 and 3.6
TestRunner
- The UI test runners provide a check box to enable/disable the custom class loader. The user is warned when running a second test with the non loading class loader.
- Renames to address file name length limitation on MacOS:
- LoadingClassPathTestCollector -> LoadingTestCollector
- SimpleClassPathTestCollector -> SimpleTestCollector
Framework
- Added TestSuite.getName()
Builds
- Updated the build script for Ant 1.3.
Fixed Bugs (SourceForge Bug Tracker Ids)
[ #229753 ] assertEquals on NaN and Infinity does not work correctly
[ #229287 ] Class Name too long "SimpleClassPathTestCollector"
[ #229609 ] Stack Filtering missing in textui.TesRunner
[ #229870 ] Clicking on ... after tests failed gives NPE
[ #229974 ] Incorrect icon shown for first element in Swing GUI
[ #230581 ] swingui.TestTreeModel: results of decorated testcases...
[ #230971 ] Make junit.extensions.TestDecorator.getTest() public
[ #231569 ] DocBug: JUnit Test Infected: Programmers Love Writing Tests
[ #232645 ] BaseTestRunner.getTest loses exception information
[ #233094 ] TestSuite masks exceptions
[ #410967 ] No icon provided for first test
[ #230745 ] ClassPathTestCollector sometimes lists classes in duplicate
Documentation
- Added documentation about the properties supported by TestRunners.
- Updated the FAQ
Summary of Changes between 3.4 and 3.5
Framework
- Added TestSuite.addTestSuite(Class testClass)
- Added assertEquals methods for all primitive types: float, boolean, byte, char, int, short
- The signature of TestListeners.addFailure(Test test, Throwable t)
This method allows to create a TestSuite with a class containing test cases directly.
Instead of writing suite.addTest(new TestSuite(AssertTest.class)) you can now write suite.addTestSuite(AssertTest.class);
was changed to addFailure(Test test, AssertionFailedError t)
TestRunner
- The Swing TestRunner provides an experimental feature to browse test classes. There is an additional browse ("...") button besides the suite combo. It shows a simple dialog to select a test class from a list. Different strategies to locate Test classes are supported and you can plug-in your own strategy. This allows to leverage functionality provided by an extension API of an integrated development environment (IDE). To define a custom test collector you 1) implement the junit.runner.TestCollector interface and 2) add an entry to the junit.properties file with the key TestCollectorClass and the name of your TestCollector implementation class as the key:
- simple (junit.runner.SimpleClassPathTestCollector) - considers all classes on the class path on the file system that contain "Test" in their name. Classes in JARs are not considered.
- loading (junit.runner.LoadingClassPathTestCollector) - loads all classes on the class path and tests whether the class is assignable from Test or has a static suite method.
- The Swing TestRunner now provides an additional test result view that shows all tests of the executed test suite as a tree. The view shows the success status for each test. The view is shown as an additional tab in the TestRunner window. In previous versions of JUnit this view was shown in a separate window.
- The failure panels in the Swing and AWT TestRunners filter the exception stack trace so that only non-framework stack frames are shown.
- There is support to plug-in a custom failure panel that provides additional functionality like navigating from a failure to the source. To do so you implement the junit.runner.FailureDetailView interface and register the implementation class in the junit.properties file under the key FailureViewClass, for example
- The Swing and AWT TestRunners now understand an additional command line argument "-noloading". When this argument is set then the standard system class loader is used to load classes. This is an alternative to setting the loading property to false in the junit.properties file.
- Swing TestRunner - the maximum test history length shown in the suite combo can be defined in the junit.properties file with the key maxhistory.
- BaseTestRunner.getLoader() is no longer a static method and can now be overridden in subclasses.
- BaseTestRunner removed dependency on JDK 1.2.
- Swing TestRunner - fixed the problem that a suite name was sometimes duplicated in the history combo.
- Swing TestRunner - the Run button is now the default button.
- Output string truncation can now be controlled by adding the maxmessage key with the desired maximum length to the junit.properties file. Setting maxmessage to -1 means no output truncation.
- The Text TestRunner now shows the summary at the very end so that you don't have to scroll back.
TestCollectorClass=junit.swingui.LoadingClassPathTestCollector
This class has to be installed on the class path.
JUnit provides two different TestCollector implementations:
Notice: that both TestCollectors assume that the class files reside are kept in the file system. This isn't case in VA/Java and they will not work there. A custom TestCollector is required for VA/Java.
FailureViewClass=MyFailureViewClassName.
Tests
- TextRunnerTest now only depends on a nonzero status to indicate abnormal termination.
- TextRunnerTest now also passes on JDK 1.1.*. It uses the -classpath command line argument instead of -cp.
Documentation
- Add an FAQ entry about what to do when the junit tests provided with the distribution can't be found.
Older Change Notes
Changes between 2.1 and 3.4 Changes between 1.0 and 2.1
Contents of the Release
README.html | this file |
junit.jar | a jar file with the JUnit framework and tools |
src.jar | a jar file with the source code of the junit framework |
junit | the source code of the JUnit samples |
samples | sample test cases |
tests | test cases for JUnit itself |
javadoc | javadoc generated documentation |
doc | documentation and articles |
Installation
Below are the installation steps for installing JUnit:- unzip the junit.zip file
- add junit.jar to the CLASSPATH. For example: set classpath=%classpath%;INSTALL_DIR\junit3\junit.jar
- test the installation by using either the batch or the graphical TestRunner tool to run the tests that come with this release. All the tests should pass OK.
- for the batch TestRunner type:
- for the graphical TestRunner type:
- for the Swing based graphical TestRunner type:
Notice: that the tests are not contained in the junit.jar but in the installation directory directly. Therefore make sure that the installation directory is on the class path
java junit.textui.TestRunner junit.samples.AllTests
java junit.awtui.TestRunner junit.samples.AllTests
java junit.swingui.TestRunner junit.samples.AllTests
Getting Started
To get started with unit testing and JUnit read the Java Report article: Test Infected - Programmers Love Writing Tests.This article demonstrates the development process with JUnit in the context of multiple currency arithmetic. The corresponding source code is in junit\samples\money.
You find additional samples in the junit.samples package:
- SimpleTest.java - some simple test cases
- VectorTest.java - test cases for java.util.Vector
Documentation
JUnit Cookbook
A cookbook for implementing tests with JUnit.
Test Infected - Programmers Love Writing Tests
An article demonstrating the development process with JUnit.
JUnit - A cooks tour
Javadoc
API documentation generated with javadoc.
Frequently asked questions
Some frequently asked questions about using JUnit.
TestRunner Preference settings
Describes the preferences settings that can be configured for the JUnit TestRunners.
License
The terms of the common public license used for JUnit.
Extending JUnit
Examples of possible JUnit extensions can be found in the junit.extensions package:- TestDecorator - A decorator for Test. You can use it as the base class for implementing decorators to extend test cases.
- ActiveTestSuite - A TestSuite which runs each test in a separate thread and waits until they are all terminated.
- TestSetup - A Decorator to set up and tear down additional fixture state. Subclass TestSetup and insert it into your tests when you want to set up additional state once before the tests are run.
- ExceptionTestCase - A TestCase that expects a particular Exception to be thrown.