Junit Next Release

JUnit 4 will be the first OpenSource release in the sense that other people's contributions will predominate over KentBeck and ErichGamma's.

Here are the features to be added in JUnit 4:

General goal

Define the deadline for the version 4.0 (VladimirBossicard)
Runs on standard JDK. Need to decide whether giving up JDK 1.1.7 compatibility.

  The current status of the survey on SourceForge is 25 (JDK 1.1.7 compatible) 
  to 60 (not JDK 1.1.7 compatible.

Encourage more developers.
4.0 changes should come from someone else.

Features - framework

Classloader user problem : possibility to modify the list of reloaded classes dynamically, w/ user interaction (done - VladimirBossicard)

The excluded filter mechanism in JUnit 3.7 is fragile. See the detailed analysis
of the JAXP problem that was posted to the junit mailing list. We should look for
for an alternative. The reloading 
should work without having the user tweak the list of excluded filters. A "green"
idea would be to load _all_ user classes by a new class loader instance for each test run.
In other words only system classes on the bootstrap class path will not be reloaded  
in each run. The JDK 1.2 delegating class loader mechanism combined with the
URLClassLoader should enable this. However, this needs some experimentation (ErichGamma)

Multi-thread test support (I submitted a TestDecorator? at sourceforge a few months ago that handles this via a ThreadGroup? and the uncaughtException method -- GregVaughn)
Start architecting in the basics needed to allow others to support key features while still resting on-top of the current source tree. i.e. Look at the common patterns (if any) used of how people have implemented the special features of JXUnit/JakartaCactus(previously known as J2EEUnit)/ etc.. and start putting in place mechanisms to make them easier to do from the root tree. The goal here is to minimize the number of branches out there for extensions that could have been done using some basic extensibility pattern.
Place messages in a resource bundle (ErichGamma)
Add a method to the TestCase interface Test.setUp( Properties p ), so that tests can be supplied relevant context information. One example would be the contents of a .properties file containing identities of database records to use in tests. A related example would be the same information, but supplied by a ServletTestRunner using properties harvested from the servlet's deployment descriptor. The TestRunner is then free to obtain the properties in whatever manner makes sense to it. ( DavidBullock )
Add a method to the TestCase interafce Test.setUp( TestContext? ctx ), so that the tests can have access to services such as logging. An example of this is in the Servlet environment, where PrintWriter? for trace statements are obtained from a ServletContext? ( as are many other services ). If you like, the Properties ( above ) can be obtained from the TestContext? interface. ( It is important that TestContext? is a true interface, to give TestRunners? maximum flexibility ). ( DavidBullock )
I'd like to see TestSuites announce startup and completion, as well as test cases. --RobertWatkins
I'd like to see the TestSuite constructor taking a Class object to first check whether the test class has a suite() method before using reflection to assemble the test methods. -- JbRainsberger

Features - runner

Analyze a failure in detail.
Does the Jar loading really work? There are not enough tests!

Rather than loading JARs manually we should leverage the JDK 1.2.2
URLClassLoader class (ErichGamma)

Features - ui

UI (proposed and almost finished - VladimirBossicard)
Encourage other people to implement new GUIs (one new gui done - VladimirBossicard)
Add a new package with a UI we will include in the JUnit release.
Make the exclusion mechanism more accessible in the UI. (done - VladimirBossicard)
Help support (skeleton done - VladimirBossicard)
Make FAQ more accessible (in the doc or help - VladimirBossicard)

Features - misc

Test log in XML
Test evolution over time
Encapsulate the basic JUnit runner in a bean (-> define a borderline between the the core JUnit code and the applications (textui, swingui) using it). It allows 3rd party applications to focus on the core functionalities of JUnit and give us more freedom to modify the textui and swingui runners. We can then only guarantee backward compatibility for the bean and not the different application (VladimirBossicard).
Plug-in architecture for the bean (see proposition - VladimirBossicard)
Worldwide JUnit server with local variations

What variations are you thinking of? (VladimirBossicard)

Development process

Stay IDE neutral
Set up a CVS tree to enable nightly build (VladimirBossicard)
Introduce beta version before official release
Set up a group of beta testers to have a wide panel of JUnit users and projects (VladimirBossicard)
Rules for contributing

To Do Items for 4.0 (from http://sourceforge.net/projects/junit)

[ #229959 ] Missing old functionality from the "Test Browser" window (on it's way - VladimirBossicard)
[ #231767 ] "Failure/Error" list not updated correctly (icons)
[ #404165 ] Add properties from command line (have propositions - VladimirBossicard)
Define a runner API for the TestRunners?, currently there is no consistent API (have propositions - VladimirBossicard)

Here are features that will just have to wait until later: