Provide @Rule alternative to SpringJUnit4ClassRunner [SPR-7731]

[spring-projects-issues]

Dave Syer opened SPR-7731 and commented

Overview

Sometimes (always?) it would be nice to have a @Rule implementation that did the job of the SpringJUnit4ClassRunner.

The main motivation for this is to be able to use other runners (e.g. @Parameterized, @Categories, Mockito, etc.).

There might even be a case for deprecating the runner in favor of a @Rule?

---

Further Resources

• @Rules annotation at class level junit-team/junit4#200
• JUnit should have an exhaustive listener framework junit-team/junit4#444
• Add support for test pre-processors junit-team/junit4#766
• SPR-10217 Implement JUnit 4 Support using Rules #222
• https://github.com/mmichaelis/spring-aware-rule

---

Attachments:

• SpringContextRule.java (4.72 kB)
• SpringContextRule.java (4.49 kB)
• spring-test-4.2.0.BUILD-SNAPSHOT.jar (501.52 kB)

Issue Links:

• Introduce a TestExecutionListener for DbUnit [SPR-6593] #11259 Introduce a TestExecutionListener for DbUnit ("Cloned from")
• Document SpringClassRule and SpringMethodRule in the reference manual [SPR-13037] #17629 Document SpringClassRule and SpringMethodRule in the reference manual ("is depended on by")
• JUnit @Rule executes outside of transaction when using the TransactionalTestExecutionListener [SPR-9232] #13870 JUnit @Rule executes outside of transaction when using the TransactionalTestExecutionListener ("is depended on by")
• Implement JUnit 4 Support using Rules [SPR-10217] #14850 Implement JUnit 4 Support using Rules ("is duplicated by")
• Add support for parameterized JUnit 4 tests in the Spring TestContext Framework [SPR-5292] #9965 Add support for parameterized JUnit 4 tests in the Spring TestContext Framework

25 votes, 30 watchers

[spring-projects-issues]

Neale Upstone commented

There's a push for this from the JUnit end, where David Saff has suggested a move to @Rule for Spring test, response to my desire for more DRYness: https://github.com/KentBeck/junit/issues/100#issue/100/comment/779203.

[spring-projects-issues]

Neale Upstone commented

Sam.

I'm looking into this and will hopefully get to prototype it on Thursday.

Let me know if you make a start. I suspect you may find some limitations to the @Rule/@ClassRule implementation, but this patch of mine may be what we need: nealeu/junit@da6c5e5

I'd be interested on feedback on whether this looks useful for the @Rule related JIRAs on Spring Test

[spring-projects-issues]

Neale Upstone commented

Here's a proof of concept based on a reasonable patch for ComplexRule support in JUnit 4.9.

To use, you'll need the two commits from this branch: https://github.com/nealeu/junit/commits/complex-rules.

i.e. checkout the complex-rules branch from git@github.com:nealeu/junit.git

[spring-projects-issues]

Neale Upstone commented

Sam & Dave

If you can find an elegant way to avoid the need for ComplexRule, then I'll buy you a beer!

Failing that, I suggest you checkout my JUnit git branch and use the attached file as a starting point, such that you can give some yay-nay feedback in time to get some agreement on what support is needed at the JUnit end.

As noted in the javadoc of my attachment, I think this would be most elegant if JUnit also allowed @Rule(class) on annotations (i.e. both instantiates the rule for us, and looks on annotations for meta-annotations).

I'll park it there for now.

[spring-projects-issues]

Dave Syer commented

I'll have a look at your junit code. Any chance of an executive summary of what it does and why it's important for Spring test context? Is it just because a Spring test context manager has a role at the class and the method level? I imagine you could hack around that with a static instance of a normal @Rule in your test case?

Note that you can submit pull requests to Spring via https://github.com/cbeams/spring-framework.

[spring-projects-issues]

Neale Upstone commented

Pull requests... that's a bit 21st century isn't it :p Didn't know, so thanks. Forkin marvellous as some might say.

Static @Rule. Possibly, but that's not your only issue. The other is that you need the java.lang.reflect.Method reference, which is the second commit in my junit fork.

With just that enhancement to JUnit's Description class, your job becomes a lot easier, as the static @Rule can call Description.getMethod() and test for null to determine if it's the @ClassRule or method @Rule that's being evaluated.

Introducing ComplexRule does a couple of things (as you'll see at nealeu/junit@da6c5e5#diff-0):

• it has 2 methods one which is called for @ClassRule statements and one which is called for @Rule
• it adds Class<?> clazz to the applyClassRule() version and Object target to the applyMethodRule() version

Actually I didn't need the Class param, as that's avail as Description.getTestClass().

So, in summary, it looks like minimal requirements at JUnit end are:

• add Object target to TestRule.apply()
• add getMethod() to Description

I could rustle up an alternative JUnit patch later if that looks about right.

Dave, I've given you commit rights on my junit fork if you want to hack on what I've already done.

[spring-projects-issues]

Neale Upstone commented

Take 2: Just pushed to branch enhanced-rule what I think is sufficient for above.

See https://github.com/nealeu/junit/commits/enhanced-rules

[spring-projects-issues]

Neale Upstone commented

Tweaked to work with lower impact enhanced-rule proposal for JUnit instead of introducing ComplexRule.

[spring-projects-issues]

Neale Upstone commented

There's a related JUnit issue, https://github.com/KentBeck/junit/issues/#issue/32, which looks for JUnit to manage the instantiation of Rules. I've commented on how I think this can go forwards and requested feedback before diving in with another proactive patch. For replacing features currently requiring Runners I'm suggesting that we're really looking at a broader interceptor model, which would be a good foundation for both Rules and Runner replacements.

[spring-projects-issues]

Dave Syer commented

I think an interceptor model would be good for JUnit rules - I commented to that effect on one of their issues (not sure if it was that one). If a rule had the ability to modify the chain it was involved in by returning a decorated version it would open up a lot of useful possibilities (e.g. switching off the @Before/@After which is a much requested feature). Good luck with getting that into JUnit.

[spring-projects-issues]

Neale Upstone commented

Looks like modifying the chain could be on the cards:

From https://github.com/KentBeck/junit/issues/199:

The interfaces proposed might change, or be combined. We also might consider making BlockBuildRule an abstract class, so that future extension points could be added without breaking extenders.

This change would also introduce a base RuleChainer for BlockJUnit4ClassRunner, which would return Rules representing the basic built-in wrapper chain (which would need to be re-expressed as rules):

[ExpectingExceptions, PotentialTimeout, WithBefores, WithAfters, WithRules]

And for ParentRunner:

[WithBeforeClasses, WithAfterClasses, WithClassRules]

This would allow BlockBuildRules to insert, re-order, delete, etc. these built-in wrappers.

[spring-projects-issues]

Sam Brannen commented

Example of a limited, partial solution in the wild: SpringIntegration Rule from the Thucydides project.

[spring-projects-issues]

The Alchemist commented

Any updates on this?

[spring-projects-issues]

Sam Brannen commented

The Alchemist, this issue is currently assigned to the 3.3 backlog and will be reassigned to a concrete release pending available resources and demand from the community.

Regards,

Sam

[spring-projects-issues]

Sam Brannen commented

Pull request submitted by Philippe Marschall in conjunction with #14850:

#222