Kent Beck and David Saff have posted the second release candidate of JUnit 4, though I'd classify this as amore of an alpha (i.e. feature list and API still subject to change) than a real release candidate. According to Saff,
The first and most important point is this: early adopters, 99% of your JUnit 4 test cases still work, and now work better than before!
Back in October, Kent said "The remaining functionality we need to add is a way to specify test suites that is represented in source code and works with automated refactoring tools. Once that is in place we will javadoc everything, package it, and deploy." We thought about it, and realized that what this really meant was
- JUnit's extension mechanism should be so powerful that test suites can be just another extension.
- Extensions should work seamlessly with IDE test runners, meaning
- Since IDE's and UI's like to display the names of tests before they're run, and match up successes and failures with these names, there must be a standard way to display the components of an extended test suite.
- There should be a standard way to run just a single method from a test class, with extension-defined setup and teardown behavior
- JUnit 4 should respond gracefully to user cancellation requests that come in the middle of a run
- Extensions should work seamlessly with JUnit 3 test runners
- There should be a simple API for running test classes, sets of test classes, single test methods, and any other test specification.
To support these goals, we needed the following concepts:
- Runner. An extension to JUnit will likely define a custom subclass of Runner.
- Plan. Each Runner must report a Plan, a hierarchical tree of the names of the tests it will run. Test events are reported with respect to leaves in this tree.
- Request. A Request is a specification of the desired tests to be run. Extensions may also define custom subclasses of Request, in order to, for example, read tests to be run out of an XML file--if you think that's a good idea. :-)
There is an important distinction between Requests and Plans. A Request might be "Please run all tests in class ValidationTest", with the corresponding Plan being "I will run methods foo, bar, baz, and foobar in class ValidationTest".
Again, nothing has changed about the basic annotation-based test definition API, so your existing test cases still work. A revised overview of the packages and classes as they stand now, and how to run a JUnit 4 test using a JUnit 3 runner, is at
http://people.csail.mit.edu/saff/junit4.0rc2api.txt
We believe that this robust extensibility, explicit IDE support, backward compatibility, and simple API are worth the extra time you've waited. We're very interested in feedback. To try things out, you can download the code from CVS, or, for a limited time only, download a list-members-only distribution from
http://people.csail.mit.edu/saff/junit4.0rc2.zipWe're especially interested in:
- Results of running JUnit 4 tests with various JUnit 3 runners.
- Experiences using JUnit 4 to write tests.
- New Runners and Requests.
Remember that this is not the final release--the implementation and API may still change as we respond to your comments and shake loose the remaining issues. Thanks,
Java 5 is required.