Introduce adapters for JUnit 4 Rules

[sbrannen]

Goals

Introduce adapters for common JUnit 4 Rules in the junit-jupiter-engine.

The dependency from junit-jupiter-engine to JUnit 4 must be an optional dependency.

This support should be automatically enabled if junit-4.x.jar is on the classpath.

Proposed Candidates

• ExpectedException
• ExternalResource
• Verifier

Related Issues

• Demonstrate migration path from JUnit 4 to JUnit 5 #169
• Document compatibility with JUnit 4 TestRules #343

Related Blog Posts

• http://www.codeaffine.com/2016/04/06/replace-rules-in-junit5/
• http://blog.codefx.org/libraries/junit-5-conditions/

[kcooney]

@sbrannen Is the proposal to allow these three Rules in JUnit Jupiter tests but not others?

[sbrannen]

@kcooney, yes, that's correct.

The JUnit 5 team analyzed the existing rules in JUnit 4 and selected ones that can be supported with current extension APIs in JUnit Jupiter.

JUnit 4 rules not in the above list cannot currently be supported without some sort of Statement-like extension which is currently not planned for JUnit Jupiter.

[mlevison]

Suggestion (from vacation again, excuse top posting).

Adapters will promote the continued use of the old rules.

Consider as an alternative providing mappings. For bonus points, automate
the mapping via regex (of simple enough) or a full blown test rewriter (ie
Java code).

NB I'm writing from my phone at a Gaelic football tournament. I've not
reflected on real code.

Cheers
Mark

On Jul 30, 2016 12:03 PM, "Sam Brannen" notifications@github.com wrote:

@kcooney https://github.com/kcooney, yes, that's correct.

The JUnit 5 team analyzed the existing rules in JUnit 4 and selected ones
that can be supported with current extension APIs in JUnit Jupiter.

JUnit 4 rules not in the above list cannot currently be supported without
some sort of Statement-like extension which is currently not planned for
JUnit Jupiter.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#433 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAImZjvFJJv1pqSW1jJWdxO_SvydbGxiks5qa4PugaJpZM4JUGOo
.

[kcooney]

Two points:

1. There is no need to support ExpectedException for JUnit Jupiter tests. The expectThrows and assertThrows methods are more powerful. In addition, ExpectedException is easy to use incorrectly so we shouldn't encourage it's use for projects that can use lambdas.
2. This doesn't solve the need for a Rule-like extension point that can be used by JUnit Jupiter tests and JUnit Vintage tests, so deveopers with a large code base can build simple reusable extension points that they can use in both styles of tests while they slowly migrate their tests to JUnit Jupiter. Did the JUnit Lambda team discuss my prototype for such an extension?

[marcphilipp]

There is no need to support ExpectedException for JUnit Jupiter tests. The expectThrows and assertThrows methods are more powerful. In addition, ExpectedException is easy to use incorrectly so we shouldn't encourage it's use for projects that can use lambdas.

I agree that expectThrows and assertThrows are more powerful. And we will absolutely encourage people to use them.

This doesn't solve the need for a Rule-like extension point that can be used by JUnit Jupiter tests and JUnit Vintage tests, so developers with a large code base can build simple reusable extension points that they can use in both styles of tests while they slowly migrate their tests to JUnit Jupiter.

Indeed, this proposal addresses a different scenario. We have been approached multiple times by developers who want to use Jupiter but are awed by the amount of tests they would need to migrate in order to have old and new tests use the new engine. For such use cases, it will be a lot easier just to replace all the annotations through a script and keep using the most common rules (for now). E.g. replacing ExpectedException with assertThrows is not a simple mechanical change.

Did the JUnit Lambda team discuss my prototype for such an extension?

I'll reply on #169 regarding your prototype.

[kcooney]

@marcphilipp instead of special-casing these two rules, have you considered modifying these rules to implement an interface that JUnit Jupiter could support? That would allow third-party developers to potentially update their rules to work with JUnit Jupiter. Of course, then people who want to easily migrate their tests using this migration tool would beed to upgrade to JUnit 4.13 (at least if they wanted the tool to migrate tests using those rules).

It would be quite easy to retrofit these rules to implement my TestFixture interface 😉