OLD Suggestions for JUnit Lambda

Collection of suggestions for the upcoming JUnit Lambda project or JUnit 5.

Core principals

See Core Principals.

Programming Model

See Programming Model.

API / SPI for Running and Reporting Test Execution and Results

See API for Running and Reporting Tests.

Extending and Modifying JUnit's standard behavior

See Extending JUnit's Standard Behaviour.

Use of Latest Java Language Features

• Use Lambdas to specify code that should fail with exceptions
• Use Lambdas to specify hierarchies of tests
• Use Lambdas to allow test creation on the fly
• Use Lambdas to allow the creation of expensive test reports only in case of a test failure
• Use interface default methods for ...
• Use inherited attributes for ...

Contexts as an abstraction over Class- and Test-based setup and teardown

See Contexts as an abstraction over Class-based and Test-based setup and teardown.

Miscellaneous

• Provide backwards compatibility to JUnit 4 or have a reasonable migration path?

  • Change base package to allow separation between JUnit 4 and 5?

• What JDK versions should be supported?

  • Max version for Android?
    • I strongly feel that the core JUnit library would work on Android. If we need to use language features not supported by Android (lambdas, default methods etc) we should do that in an extension library. We could use APIs not supported by Android by checking the SDK version. - @kcooney
  • Could the Runner API require higher version than JUnit core?
    • I am confused by this... wouldn't the core API need to call into the runner API? - @kcooney

• Should we consider Jigsaw for modularization?

  • Jigsaw seems to be designed for the JDK itself, not third-party Libraries. - @kcooney
    • Not quite. According to a talk by Brian Goetz at JAX this year, Jigsaw will bring a new modularization system for Java applications in general - maybe this helps. @kmpukall
    • Either way, thus requiring Jigsaw in the core code would mean JUnit wouldn't work on Android - @kcooney

• Minimum things to keep from JUnit 4 (maybe only as alternatives to new approaches)

  • @Test
  • @Theory
  • Assert.nameYourFavouriteAssertionMethod

• As author of Degraph I think a cycle free design on package level is really helpful to create a clean structure, and of course I'd be glad to help creating that and verifying it using Degraph. - @schauder

• Should JUnit include its own assertions, delegate to a different library, or no assertions at all? @schauder

  • discussion on this page: Assertion API

• Replace Categories based on classes with tags and/or key-value pairs - @schauder

• Separate reporting result of failed preconditions (prior to calling the method being tested) and assertions. I want to know whether a test fails because the preconditions were not met or whether it was because of a change in the method being tested. (Edit: Perhaps this would not be an issue if all setup and preconditions are defined in the @Before/setup-methods through the use of hierarchical test contexts.) @alixwar

Design Ideas

• Components Design Sketch
• Possible Layers