## 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:

publ`ic 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.