JUnit 4.8

Goal of this page is to encourage the community
to participate in the discussion about development of
new IDE features in area of the JUnit Testing.
Please, feel free to use discussion
subpage for questions, comments, proposals, etc.

As the JUnit 4.8.2 is released will be better to have support of its new features in the NetBeans IDE.

The NetBeans 6.9 relies on the JUnit 4.5 yet.

Contents

JUnit Release Notes

The list below contains the links to the JUnit Releases Notes since the version 4.5 that is used in the NetBeans 6.9.

4.6, 4.7, 4.8, 4.8.1, 4.8.2

JUnit Features

JUnit Feature Since
MaxCore 4.6
Test scheduling strategies 4.6
Comparing double arrays 4.6
Filter.matchDescription API 4.6
Rules 4.7
Categories 4.8

Support of New JUnit Features

Please, consider this as a wish list.
There are no guaranties that the features described below will be implemented in the next version of the NetBeans.

MaxCore

Established in the JUnit 4.6.

The implementation of the JUnit includes a new experimental Core, MaxCore. MaxCore remembers the results of previous test runs in order to run new tests out of order. MaxCore prefers new tests to old tests, fast tests to slow tests, and recently failing tests to tests that last failed long ago.

See also:

Benefits:

  • Optimization of execution of the unit tests lets to organize automatic continuous testing inside IDE during development. So that a developer will see results of the unit tests "on the fly", i.e. immediately after changing of the test implementation.
  • No extra actions are required in the IDE to get the results of the tests under development.

Risks:

  • The experimental API will be changed in the future versions of the JUnit.
  • Status of the JUnit Max project is unclear: "JUnit Max is no longer being actively developed or sold."

Test scheduling strategies

Established in the JUnit 4.6.

JUnitCore includes an experimental method that allows to specify a model of the `Computer` that runs the tests.

Currently, the only built-in Computers are:

  • the default serial runner,
  • two runners provided in the `ParallelRunner` class:
    • ParallelRunner.classes(), which runs classes in parallel, and
    • ParallelRunner.methods(), which runs classes and methods in parallel.

Benefits:

  • A developer can choose an optimal strategy of execution of the unit tests. It lets to use most appropriated strategy in testing of the Java project under development.

Risks:

  • It is non-stable JUnit feature, and may be merged with MaxCore in some way in the future.

Comparing double arrays

Established in the JUnit 4.6.

Arrays of doubles can be compared, using a delta allowance for equality.

Conclusion: The NetBeans IDE will support this feature automatically after upgrading of the JUnit jar via existing facility of the code completion.

Filter.matchDescription API

Established in the JUnit 4.6.

Since 4.0, it has been possible to run a single method using the Request.method API. In 4.6, the filter that implements this is exposed as Filter.matchDescription API.

Benefits:

  • More flexible control of the test execution will be possible via using of new Filter.matchDescription API and class Description.
    For example, IDE can support several test run configurations associated with a project. In this case, a user can select a desired configuration from the list of defined test run configurations.

Risks:

  • TBD

Rules

Since 4.7

Rules allow very flexible addition or redefinition of the behavior of each test method in a test class.

For more on this feature, see:

Support

IDE might provide the action Add Rule that can be applied to a test class. The action will generate code of the rule chosen by a user from list. The list of rules should include:

  • all the pre-defined rules, including ErrorCollector, ExpectedException, ExternalResource, TemporaryFolder, TestName, TestWatchman, Timeout, Verifier.
  • all the rules that are additionally defined in the project, i.e. all classes, including nested classes, that implement the interface org.junit.rules.MethodRule:
    • under the "test" root folder
    • in the project libraries (JARs)

A common pattern is used to generate code of the class member (field) for a rule:

@Rule
public %RuleClass% %RuleFieldName% = new %RuleClass%(<arg list (if any)>);

Risks: Minimal.

Categories

From a given set of test classes, the Categories runner runs only the classes and methods that are annotated with either the category given with the @IncludeCategory annotation, or a subtype of that category. Either classes or interfaces can be used as categories. Subtyping works, so if you say @IncludeCategory(SuperClass.class), a test marked @Category({SubClass.class}) will be run.

You can also exclude categories by using the @ExcludeCategory annotation.

Support TBD

Risks: TBD

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo