Summary of Changes between 1.0 and 2.1
The focus of this release was to refactor parts of the framework and to
make it more consistent. In addition, we have simplified the writing and
running of tests.
-
We renamed the package prefix for all junit classes from "test" to "junit."
-
This version extracts test
suites automatically. TestSuite now provides a constructor TestSuite(Class
theClass). This constructor adds all the methods from the given class
starting with "test" as test cases to the suite. This avoids you having
to update the suite method manually when adding a new test. For example,
the suite() method of the VectorTest can now be written as:
public static Test suite() {
return new TestSuite(VectorTest.class);
}
-
Several new assert methods were added:
-
assertNotNull(Object object)
-
assertNotNull(String message, Object object)
-
assertNull(Object object)
-
assertNull(String message, Object object)
-
assertSame(Object actual, Object expected)
-
assertSame(String message, Object actual, Object expected)
-
fail()
-
fail(String message).
-
Exceptions during setUp() and tearDown() are now caught and reported.
-
A warning is now given when a TestCase class isn't public or has no test
methods.
-
All the assert methods are now public.
-
Both the batch and the interactive TestRunner no longer require that the
Test class provides a static suite() method. If there is no suite method
all the public void methods starting with "test" and no arguments are run
(see above). There is a new variation of the graphical TestRunner (junit.ui.TestRunner)
the LoadingTestRunner. The LoadingTestRunner uses a custom class loader
to reload user classes for each test run. This avoids that the TestRunner
tool needs to be restarted for each run. The old TestRunner attempted to
address this by making assumptions about the garbage collection of classes
which were not portable. In particular, the old scheme would not
work at Notice, in an environment with dynamic object migration support
or hot code updating like VisualAge for Java this isn't an issue.
There, the environment takes care of updating the code and objects
run by the TestRunner. When using JUnit with VisualAge for Java, just use
the standard junit.ui.TestRunner.
-
When the graphical TestRunner is run under Visual Age for Java there is
an additional run button to rerun a failed test. This is typically used
to set a breakpoint in the test method and to rerun it under the debugger.
-
The TestRunners support the command line option -c TestClassName. This
allows you to run them as VisualAge for Java tools.
Once you have JUnit installed as a VAJ tool you can select the Test
class and run its tests from a VAJ menu (see how to run JUnit as a VisualAge
for Java tool).
-
The batch TestRunner supports a runAndWait method to run a suite and wait
until the user types RETURN.