Add support for parameterized JUnit 4 tests in the Spring TestContext Framework [SPR-5292]

[spring-projects-issues]

Tuomas Kiviaho opened SPR-5292 and commented

SpringJUnit4ClassRunner is unaware of @Parameters annotation that normally is processed with JUnit's own Parameterized runner.

---

Affects: 2.5.6

Attachments:

• ConstructorArgFromSpringConfigTestRunner.java (3.71 kB)
• junit4_SpringParameterizedRunner.java (5.60 kB)
• ParameterizedDirtiesContext.java (5.29 kB)
• SpringJUnit4ParameterizedClassRunner.java (22.37 kB)
• SpringJUnit4ParameterizedClassRunner.java.v2 (3.20 kB)
• SpringParameterizedRunner.java (5.03 kB)

Issue Links:

• Provide @Rule alternative to SpringJUnit4ClassRunner [SPR-7731] #12387 Provide @Rule alternative to SpringJUnit4ClassRunner
• Junit4 support [SPR-3104] #7791 Junit4 support

Referenced from: commits spring-attic/spring-framework-issues@b9c8f10, spring-attic/spring-framework-issues@239b3fe

42 votes, 46 watchers

[spring-projects-issues]

Jon Burgin commented

Here is our solution. Enjoy!

[spring-projects-issues]

Jon Burgin commented

That is our solution is attached above. :)

[spring-projects-issues]

Mark van der Voort commented

I think there are a few problems with the solution sketched.

• It is not compatible with junit4.7
• Testcases will be treated as testclasses, so any class level DirtiesContext annotations will cause the the context to be refreshed after each case, rather than after the entire set

[spring-projects-issues]

Matt Brown commented

Just curious - should the value of the Fix Version (which has been bumped from 3.0 RCs to 3.1 milestone) be interpreted as meaning that this support will be added in 3.1?

[spring-projects-issues]

Juergen Hoeller commented

Indeed, we're usually setting the fix version as a kind of work plan. So in this case, the plan is indeed to provide this in 3.1 M2 towards the end of this year.

Juergen

[spring-projects-issues]

Manjuka Soysa commented

As someone pointed out, the previous file does not work with the latest JUnit.
The new SpringParameterizedRunner is hopefully useful for you until @Parameterized is officially supported by Spring.

[spring-projects-issues]

Dave Syer commented

A better approach to this might be to provide the Spring integration test support as a @Rule (as well as or instead of a custom Runner). There might be some limitations of that approach, but it seems worth a try. I know Iwein did this in a blog a while ago, and although he didn't complete the feature set it was pretty easy to get off the ground.

[spring-projects-issues]

Chris Beams commented

We ought to consider parameterization of profile combinations here as well. e.g.: run the same @Test with profiles [p1, p2] active, and run it again with [p2, p3] active, etc.

[spring-projects-issues]

Josef Eisl commented

I've merged Springs JUnit4 Runner (3.0.4) with JUnits Parameterized Runner (r4.8.2). Working just fine for me but not extensively tested.

[spring-projects-issues]

Marek Pietrasz commented

I am afraid current patch doesn't work with TestExecutionListener - I couldn't force it to execute beforeTestClass method.

[spring-projects-issues]

Paris Holley commented

SpringJUnit4ParameterizedClassRunner.java currently has a createTest() implementation that instantiates a new instance of the test class for each method, is this intended behavior? I ended up changing it for our needs to only create it once (so that it behaves like normal non-parameterized tests).

[spring-projects-issues]

Ryan Stewart commented

If I understand you correctly, that's not how JUnit behaves for non-parameterized tests. It always creates a new test instance for each test method. So yes, that's the intended behavior.

[spring-projects-issues]

Paris Holley commented

Ryan you are right, taking another look at javadoc for Parameterized it says its a new instance per test, probably need to take issue up with JUnit. Such behavior makes maintaining test state harder, but can be worked around.

[spring-projects-issues]

Chris Beams commented

Repro project at spring-attic/spring-framework-issues#28. Thanks, Dave.

[spring-projects-issues]

Flemming Jønsson commented

Hi Chris - I noticed your comment from a while back on this JIRA "We ought to consider parameterization of profile combinations here as well. e.g.: run the same @Test with profiles [p1, p2] active, and run it again with [p2, p3] active, etc."

I find that a very useful feature. It just so happens that we have a setup where we need this feature. So I did a small proof of concept using the SpringContextRule from spring-attic/spring-framework-issues#28 and described my approach in the SpringSource fora.

It is very rough and it requires the use of the @Parameterized.Parameters array to supply the list of profiles per test iteration. However ugly an approach it may be it works fine and serves my purpose. So I thought that others might have a similar need and posted my approach here.

Feel free to criticize or suggest improvements. Next time I don't have anything to work on during my commute I will have a look at how to make this possible using the SpringJunit4 runner.
http://forum.springsource.org/showthread.php?129462-RunWith(Parameterized-class)-with-different-set-of-Spring-profiles-per-parameter