Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/stefanbirkner/junit3
JUnit 3 only
https://github.com/stefanbirkner/junit3
Last synced: about 1 month ago
JSON representation
JUnit 3 only
- Host: GitHub
- URL: https://github.com/stefanbirkner/junit3
- Owner: stefanbirkner
- Created: 2014-02-13T22:43:43.000Z (over 10 years ago)
- Default Branch: master
- Last Pushed: 2014-02-14T07:32:10.000Z (over 10 years ago)
- Last Synced: 2023-03-14T05:30:59.909Z (over 1 year ago)
- Language: Java
- Size: 668 KB
- Stars: 3
- Watchers: 2
- Forks: 7
- Open Issues: 0
-
Metadata Files:
- Readme: README.html
Awesome Lists containing this project
README
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:
By default the simple the test collector is
used. The loading collector
is more precise but much slower than the simple one. The loading
collector
doesn't scale up when many classes are available on the class path.
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
Important:
don't install the junit.jar
into the extension directory of your JDK installation. If you do so the
test class on the files system will not be found.
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.