Question: JUnit 5/JUnit Platform support roadmap #617

Open
mkobit opened this Issue Jul 13, 2016 · 9 comments

Projects

None yet

6 participants

@mkobit
mkobit commented Jul 13, 2016

JUnit5-M1 was released on July 7th. I'm wondering, is there a plan or documentation of what needs to change in order to support JUnit 5?

@enriquezrene

What do you mean with support JUnit 5, do you wanna mix spock and junit @mkobit?

@mkobit
mkobit commented Jul 18, 2016

@enriquezrene I really enjoy the method of writing Specification, but sometimes extending or making modifications to the way Spock works is difficult. The extensions page of the current RC is still missing info around Writing Custom Extensions, which makes it somewhat difficult to understand where to do additional extensions. There are classes like IGlobalExtension and IAnnotationDrivenExtension can be used, but the way of bringing them in to me is awkward and unwieldy. You can also use @Rule, but IMO the new extension model is conceptually clearer to understand and implement.

It would also be interesting to see if any new Groovy features (like macros that I believe are coming in 2.5, current feature requests here, or other things that I am unaware of) could be used. Or also, if Groovy 3.0 and JUnit 5 could provide additional value.

I'd like to know if there have been any thoughts around what it would take to get there, and if the core developers of Spock have thoughts on this as well.

@enriquezrene

I don't think that new features from groovy can bring new features for Spock, I mean, the contribution guide explains that Java is the preferred language in order to build Spock, and groovy could be used just when you have really good reasons (https://github.com/spockframework/spock/blob/master/CONTRIBUTING.md). On the other hand, I think that if we can provide tests sample written with Junit5, and show them to Spock developers can be helpful because they may show us the spock-style in order to achieve the same behaviour or it could become a future new feature

@sbrannen
sbrannen commented Jul 24, 2016 edited

Spock and JUnit are already mixed via the Sputnik JUnit 4 Runner.

JUnit 5 introduces a completely new model for running testing frameworks (like Spock) on the JUnit Platform which departs from the Runner API in JUnit 4. Specifically, the JUnit Platform introduces a TestEngine API.

The JUnit team provides two such engines out of the box: the JupiterTestEngine for the JUnit 5 programming model and the VintageTestEngine for the JUnit 3 and JUnit 4 programming models. Furthermore, third parties are already implementing custom engines to support testing frameworks like Specsy, Spek (for Kotlin), etc.

For seamless integration with future versions of the JUnit Platform, better reporting, and more powerful IDE and build tool integration, the Spock team should consider implementing a custom SpockTestEngine that will eventually replace the need for the existing Sputnik runner.

If you have any questions about the features of the JUnit Platform, feel free to raise an issue in the JUnit 5 issue tracker.

Cheers,

Sam

@sgitt
sgitt commented Aug 3, 2016

When testing code which uses frameworks like CDI or Apache Camel it is necessary to use specialized runners like @RunWith(CdiRunner.class) or @RunWith(CamelCdiRunner). And it seems to be impossible to combine them with the Spock Sputnik runner since JUnit 4 does not allow to have multiple runners per test.

Spock itself brings support for testing Spring code (spock-spring) but if we want to use Spock to test CDI code, it is necessary to re-implement functionality of libraries like cdi-unit (which provides CdiRunner) ourselves e.g. as a JUnit rule or Spock extension which is very time consuming. Alternatively for such tests we need to switch to JUnit.

JUnit 5 allows to have multiple Extension per test (see e.g. http://blog.codefx.org/design/architecture/junit-5-extension-model). We hope that if Spock supports JUnit 5 extensions it would allow us to combine it with large number of specialized test libraries and avoid the need to switch to JUnit when testing CDI, Camel or other popular frameworks.

@leonard84
Contributor

Spock has always tried to be as backwards compatible as possible, we still support Java 6. So we would still need to support JUnit 4 for the foreseeable future (way longer than Java 6). So a big question would be how we could achieve that, without having to support two separate code bases. Another issue is that much of Spock is built around the Specification base class which is then extensively modified with AST transformations, the question would be how this would translate to the JUnit 5 model and how those extensions interact with each other.

@sbrannen

@leonard84, the best way to answer that question is to start playing around with JUnit Jupiter (i.e., JUnit 5) and see how far you get with writing extensions for Spock.

I'm not familiar with the internals of Spock (e.g., the AST transformations you mentioned and the possible repercussions of such an approach), but I'd be happy to answer any questions you may have about JUnit 5 in general. And of course... if you run into any show stoppers with regard to supporting Spock in JUnit Jupiter, I (and the rest of the JUnit Team) would be grateful if you could report your findings in the JUnit 5 GitHub issue tracker.

Cheers,

Sam

@pniederw
Contributor
pniederw commented Sep 6, 2016

@leonard84 @sbrannen JUnit 4's Runner SPI has always been a big limitation for Spock. For example, it made implementing reporting and multi-threaded test execution difficult/impractical. This is a rare opportunity to break out of this box and make sure that the new (i.e., JUnit 5) box has everything Spock needs to innovate going forward. Would love to see this happen.

@leonard84
Contributor

So that would mean Spock 2.0 with JUnit 5 as new base, if we do that we could also drop Java 6 support and other outdated framework versions.

@leonard84 leonard84 added this to the 2.0 milestone Sep 6, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment