New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design Specification for JUnit 5 Support #1037

Closed
eriwen opened this Issue Dec 19, 2016 · 35 comments

Comments

Projects
None yet
@eriwen
Member

eriwen commented Dec 19, 2016

Produce a design spec for JUnit Platform aka JUnit 5 support in Gradle core.

Related to PR gradle/gradle#946

Supporting information:
Current JUnit 5 Gradle Plugin
JUnit Javadoc
Launcher API from the JUnit User Guide

Expected Output: Reviewed design doc

@bmuschko

This comment has been minimized.

Show comment
Hide comment
@bmuschko

bmuschko Dec 30, 2016

Contributor
  • I merged the pull request gradle/gradle#946 though it will still need a lot of work. It was only the beginning of a spec.
  • I created a little prototype project that uses the JUnit Launcher API from a custom task to discover and execute JUnit 5 tests to get familiar with the feature set.
  • I opened a discussion with the JUnit team about JUnit's Java 7 compatibility and how the functionality could be leveraged in Gradle core.
Contributor

bmuschko commented Dec 30, 2016

  • I merged the pull request gradle/gradle#946 though it will still need a lot of work. It was only the beginning of a spec.
  • I created a little prototype project that uses the JUnit Launcher API from a custom task to discover and execute JUnit 5 tests to get familiar with the feature set.
  • I opened a discussion with the JUnit team about JUnit's Java 7 compatibility and how the functionality could be leveraged in Gradle core.
@sbrannen

This comment has been minimized.

Show comment
Hide comment
@sbrannen

sbrannen Dec 30, 2016

@bmuschko, that's great to see that you're experimenting with a prototype!

@bmuschko, that's great to see that you're experimenting with a prototype!

@marcphilipp

This comment has been minimized.

Show comment
Hide comment
@marcphilipp

marcphilipp Feb 4, 2017

Member

Any news on this issue?

Member

marcphilipp commented Feb 4, 2017

Any news on this issue?

@bmuschko

This comment has been minimized.

Show comment
Hide comment
@bmuschko

bmuschko Feb 5, 2017

Contributor

@marcphilipp Thanks for checking in. Unfortunately, other priorities took over so we had to put this work on ice for a while. At the moment I see two major blockers for us:

  1. JUnit does not support Java 7. The limitation is not compatible with the Gradle core code base as is. We'd likely need to develop JUnit 5 support as a completely different module from the main build based on Java 8. I'd assume that we'll need to expose additional event listeners for resolving information we'll need for test execution and report generation.
  2. We'd need to detangle and generalize our testing support.
Contributor

bmuschko commented Feb 5, 2017

@marcphilipp Thanks for checking in. Unfortunately, other priorities took over so we had to put this work on ice for a while. At the moment I see two major blockers for us:

  1. JUnit does not support Java 7. The limitation is not compatible with the Gradle core code base as is. We'd likely need to develop JUnit 5 support as a completely different module from the main build based on Java 8. I'd assume that we'll need to expose additional event listeners for resolving information we'll need for test execution and report generation.
  2. We'd need to detangle and generalize our testing support.
@marcphilipp

This comment has been minimized.

Show comment
Hide comment
@marcphilipp

marcphilipp Feb 5, 2017

Member

Thanks for the explanation. Is there anything we can do to speed things up? Have you decided when Gradle will drop Java 7 support, yet?

Member

marcphilipp commented Feb 5, 2017

Thanks for the explanation. Is there anything we can do to speed things up? Have you decided when Gradle will drop Java 7 support, yet?

@adammurdoch

This comment has been minimized.

Show comment
Hide comment
@adammurdoch

adammurdoch Feb 5, 2017

Member

I don't think building for Java 8 is a blocker, we already do Java version specific features, and will probably continue to do so. Given this, we don't necessarily need to detangle the test support. It's a good opportunity to do so, but I don't see it as a blocker.

Member

adammurdoch commented Feb 5, 2017

I don't think building for Java 8 is a blocker, we already do Java version specific features, and will probably continue to do so. Given this, we don't necessarily need to detangle the test support. It's a good opportunity to do so, but I don't see it as a blocker.

@bmuschko

This comment has been minimized.

Show comment
Hide comment
@bmuschko

bmuschko Feb 6, 2017

Contributor

@adammurdoch Thanks for your input. Let's sync up on this next week to form a concrete plan forward.

Contributor

bmuschko commented Feb 6, 2017

@adammurdoch Thanks for your input. Let's sync up on this next week to form a concrete plan forward.

@eriwen

This comment has been minimized.

Show comment
Hide comment
@eriwen

eriwen Feb 6, 2017

Member

@marcphilipp I had a chance to catch up with Adam and @bmuschko about this. Here are some questions we need to answer so that we can move forward here:

  • We definitely want to keep parallel test execution. Does the JUnit Platform either give us control over this or have this built-in?
  • Are test execution events supported? We would at least want parity with our current events (e.g. — test started, test finished, test failed)
  • Test filtering — how are filtering by category and test name supported?
  • Decide the appropriate level of future-proofing. We could expend a lot of effort and make this a separate project with stable public APIs, or we could use the same DSL, test filtering, event mechanisms which would not exercise the full power of the JUnit Platform but would allow us to provide support quicker.

I don't think it's on you to answer these Marc, but I'd love for us to schedule a chat so we have the information to start answering these questions. I also want to note that I expect we'll keep Java 7 support for some time, but as Adam said that isn't a blocker in our case.

Finally, I apologize for being silent here. We had to de-prioritize JUnit Platform support in the past couple of months for various reasons.

Member

eriwen commented Feb 6, 2017

@marcphilipp I had a chance to catch up with Adam and @bmuschko about this. Here are some questions we need to answer so that we can move forward here:

  • We definitely want to keep parallel test execution. Does the JUnit Platform either give us control over this or have this built-in?
  • Are test execution events supported? We would at least want parity with our current events (e.g. — test started, test finished, test failed)
  • Test filtering — how are filtering by category and test name supported?
  • Decide the appropriate level of future-proofing. We could expend a lot of effort and make this a separate project with stable public APIs, or we could use the same DSL, test filtering, event mechanisms which would not exercise the full power of the JUnit Platform but would allow us to provide support quicker.

I don't think it's on you to answer these Marc, but I'd love for us to schedule a chat so we have the information to start answering these questions. I also want to note that I expect we'll keep Java 7 support for some time, but as Adam said that isn't a blocker in our case.

Finally, I apologize for being silent here. We had to de-prioritize JUnit Platform support in the past couple of months for various reasons.

@marcphilipp

This comment has been minimized.

Show comment
Hide comment
@marcphilipp

marcphilipp Feb 7, 2017

Member

We definitely want to keep parallel test execution. Does the JUnit Platform either give us control over this or have this built-in?

The JUnit Platform currently does not have built-in support for parallel test execution (cf. junit-team/junit5#60). How does Gradle parallelize execution for JUnit 4? By sending separate Requests?

Are test execution events supported? We would at least want parity with our current events (e.g. — test started, test finished, test failed)

Sure, there's TestExecutionListener for that.

Test filtering — how are filtering by category and test name supported?

Filters can be specified as part of a LauncherDiscoveryRequest, e.g. there's a TagFilter (tags replace categories, you can specify the FQCN of a JUnit 4 category for backwards compatibility) and a ClassNameFilter.

I don't think it's on you to answer these Marc, but I'd love for us to schedule a chat so we have the information to start answering these questions.

Sure, when would be a good time for you? I have some spare time tomorrow afternoon/night (CET).

Member

marcphilipp commented Feb 7, 2017

We definitely want to keep parallel test execution. Does the JUnit Platform either give us control over this or have this built-in?

The JUnit Platform currently does not have built-in support for parallel test execution (cf. junit-team/junit5#60). How does Gradle parallelize execution for JUnit 4? By sending separate Requests?

Are test execution events supported? We would at least want parity with our current events (e.g. — test started, test finished, test failed)

Sure, there's TestExecutionListener for that.

Test filtering — how are filtering by category and test name supported?

Filters can be specified as part of a LauncherDiscoveryRequest, e.g. there's a TagFilter (tags replace categories, you can specify the FQCN of a JUnit 4 category for backwards compatibility) and a ClassNameFilter.

I don't think it's on you to answer these Marc, but I'd love for us to schedule a chat so we have the information to start answering these questions.

Sure, when would be a good time for you? I have some spare time tomorrow afternoon/night (CET).

@marcphilipp

This comment has been minimized.

Show comment
Hide comment
@marcphilipp

marcphilipp May 17, 2017

Member

Any news on this issue?

Member

marcphilipp commented May 17, 2017

Any news on this issue?

@eriwen

This comment has been minimized.

Show comment
Hide comment
@eriwen

eriwen May 25, 2017

Member

@marcphilipp Thanks again for the ping, and sorry for the delayed response. I am asking the team to consider this as a next priority after we get Java 9 runtime support. We'll be deciding soon and if approved work can begin after Gradle 4.0 GA. Will let you know as soon as that happens.

Member

eriwen commented May 25, 2017

@marcphilipp Thanks again for the ping, and sorry for the delayed response. I am asking the team to consider this as a next priority after we get Java 9 runtime support. We'll be deciding soon and if approved work can begin after Gradle 4.0 GA. Will let you know as soon as that happens.

@sormuras

This comment has been minimized.

Show comment
Hide comment
@sormuras

sormuras Aug 31, 2017

We're about to release JUnit 5 soon. Any news on this issue?

We're about to release JUnit 5 soon. Any news on this issue?

@sormuras sormuras referenced this issue Aug 31, 2017

Closed

Revise declarations of all @API annotations #856

20 of 20 tasks complete
@eriwen

This comment has been minimized.

Show comment
Hide comment
@eriwen

eriwen Sep 5, 2017

Member

We were not able to prioritize JUnit 5 support in Gradle 4.x thus far.

@sormuras I'm sorry for not responding to this issue sooner.

Here is the current prioritization of Epics according to our ZenHub board for our Core team (~2 people).

screen shot 2017-09-05 at 3 13 00 pm

This can change, but I'd say that we currently won't be able to implement JUnit Platform support earlier than Gradle 4.4 (~December 2017). This is due to other things coming up and a rough estimate of work (it will require significant rework of our testing bits).

Thank you for the follow-up. I'm sorry this may not have been the answer you're hoping for. Please reach out with further questions.

Member

eriwen commented Sep 5, 2017

We were not able to prioritize JUnit 5 support in Gradle 4.x thus far.

@sormuras I'm sorry for not responding to this issue sooner.

Here is the current prioritization of Epics according to our ZenHub board for our Core team (~2 people).

screen shot 2017-09-05 at 3 13 00 pm

This can change, but I'd say that we currently won't be able to implement JUnit Platform support earlier than Gradle 4.4 (~December 2017). This is due to other things coming up and a rough estimate of work (it will require significant rework of our testing bits).

Thank you for the follow-up. I'm sorry this may not have been the answer you're hoping for. Please reach out with further questions.

@mkobit

This comment has been minimized.

Show comment
Hide comment
@mkobit

mkobit Oct 5, 2017

Contributor

Now that JUnit 5 has GA , are there any next steps for the community, or is it waiting until the Gradle team can prioritize support? I'm guessing there is significant coupling on the build scan side of things so that will have to be considered.

Sidenote, there was already some work on a design spec merged in #946 but it looks like the whole folder was removed from master.

Contributor

mkobit commented Oct 5, 2017

Now that JUnit 5 has GA , are there any next steps for the community, or is it waiting until the Gradle team can prioritize support? I'm guessing there is significant coupling on the build scan side of things so that will have to be considered.

Sidenote, there was already some work on a design spec merged in #946 but it looks like the whole folder was removed from master.

@Lizard

This comment has been minimized.

Show comment
Hide comment
@Lizard

Lizard Oct 6, 2017

I'd like to second mkobit's question and want to add that from my company's end-user perspective, not having core Gradle support for JUnit 5 at the time of its release really is a bit of a nuisance, given the importance of the JUnit framework for Java development - I certainly hope that no further re-priorization of this feature will be necessary.

Lizard commented Oct 6, 2017

I'd like to second mkobit's question and want to add that from my company's end-user perspective, not having core Gradle support for JUnit 5 at the time of its release really is a bit of a nuisance, given the importance of the JUnit framework for Java development - I certainly hope that no further re-priorization of this feature will be necessary.

@JLLeitschuh

This comment has been minimized.

Show comment
Hide comment
@JLLeitschuh

JLLeitschuh Oct 6, 2017

Contributor

@Lizard The Junit 5 plugin that the Junit 5 tesam offers is really solid. The only integrations that it's missing right now is the buildscan integrations.

Contributor

JLLeitschuh commented Oct 6, 2017

@Lizard The Junit 5 plugin that the Junit 5 tesam offers is really solid. The only integrations that it's missing right now is the buildscan integrations.

@jorn86

This comment has been minimized.

Show comment
Hide comment
@jorn86

jorn86 Oct 6, 2017

@JLLeitschuh Integration with source sets other than main is also not in that plugin. And the buildscan integrations (if I understand correctly) are important for IDE integration. So while I appreciate the JUnit team providing a basic integration plugin, this really needs to be integrated into Gradle.

jorn86 commented Oct 6, 2017

@JLLeitschuh Integration with source sets other than main is also not in that plugin. And the buildscan integrations (if I understand correctly) are important for IDE integration. So while I appreciate the JUnit team providing a basic integration plugin, this really needs to be integrated into Gradle.

@Lizard

This comment has been minimized.

Show comment
Hide comment
@Lizard

Lizard Oct 6, 2017

@JLLeitschuh Thanks for your feedback. I'm afraid that according to junit-team/junit5-samples#35, exactly the integrations that I am looking for are currently missing and seem to depend on the Gradle core support. To quote the JUnit 5 developers: " [The Gradle] plugin is very simple and has many limitations, e.g. it does not use the test task. The plugin was meant as a proof-of-concept, not a long-term solution. Instead, we would like to start the discussion about how to get JUnit 5 support into core Gradle." (source: https://discuss.gradle.org/t/core-support-for-junit-platform-a-k-a-junit-5/19487). I'm afraid that at the moment, their plugin does not solve our problems.

Lizard commented Oct 6, 2017

@JLLeitschuh Thanks for your feedback. I'm afraid that according to junit-team/junit5-samples#35, exactly the integrations that I am looking for are currently missing and seem to depend on the Gradle core support. To quote the JUnit 5 developers: " [The Gradle] plugin is very simple and has many limitations, e.g. it does not use the test task. The plugin was meant as a proof-of-concept, not a long-term solution. Instead, we would like to start the discussion about how to get JUnit 5 support into core Gradle." (source: https://discuss.gradle.org/t/core-support-for-junit-platform-a-k-a-junit-5/19487). I'm afraid that at the moment, their plugin does not solve our problems.

@nskvortsov

This comment has been minimized.

Show comment
Hide comment
@nskvortsov

nskvortsov Oct 6, 2017

Contributor

@JLLeitschuh the JUnit 5 plugin offered by JUnit team totally ignores existing test events model in Gradle. That renders IDE and CI servers integration useless.

Contributor

nskvortsov commented Oct 6, 2017

@JLLeitschuh the JUnit 5 plugin offered by JUnit team totally ignores existing test events model in Gradle. That renders IDE and CI servers integration useless.

@JLLeitschuh

This comment has been minimized.

Show comment
Hide comment
@JLLeitschuh

JLLeitschuh Oct 6, 2017

Contributor

And the buildscan integrations (if I understand correctly) are important for IDE integration.

I don't think this has anything to do with IDE integration. The buildscan is the thing published to the gradle server with reporting build performance/ect..

the JUnit 5 plugin offered by JUnit team totally ignores existing test events model in Gradle. That renders IDE and CI servers integration useless.

I don't understand, maybe I'm not familiar with the event model.
For IDE support are you talking about executing Junit 5 tests with gradle and seeing those results show up in your IDE? Is that a thing you can do? I've always run my Junit tests without going through gradle.

I'm not advocating that Gradle not have integrations for Junit 5. I'm just saying that as a stopgap measure, the current features of the Junit 5 plugin have been adequate for myself.

I didn't know that the Gradle test task did so much. Is there a listing of the features that the Junit 5 integration needs to make this work for developers?

Contributor

JLLeitschuh commented Oct 6, 2017

And the buildscan integrations (if I understand correctly) are important for IDE integration.

I don't think this has anything to do with IDE integration. The buildscan is the thing published to the gradle server with reporting build performance/ect..

the JUnit 5 plugin offered by JUnit team totally ignores existing test events model in Gradle. That renders IDE and CI servers integration useless.

I don't understand, maybe I'm not familiar with the event model.
For IDE support are you talking about executing Junit 5 tests with gradle and seeing those results show up in your IDE? Is that a thing you can do? I've always run my Junit tests without going through gradle.

I'm not advocating that Gradle not have integrations for Junit 5. I'm just saying that as a stopgap measure, the current features of the Junit 5 plugin have been adequate for myself.

I didn't know that the Gradle test task did so much. Is there a listing of the features that the Junit 5 integration needs to make this work for developers?

@nskvortsov

This comment has been minimized.

Show comment
Hide comment
@nskvortsov

nskvortsov Oct 6, 2017

Contributor

I don't understand, maybe I'm not familiar with the event model.

One can attach a TestListener or TestOutputListener for a single test task or globally. This allows ide/ci to receive and handle test events and data on-the-fly.

executing Junit 5 tests with gradle and seeing those results show up in your IDE? Is that a thing you can do?

Yes, you can (at least in IntelliJ). It is very useful when running a test also requires running other tasks (think of some kind of setup or code generation) defined in Gradle.

Overall, it feels like junit-platform-gradle-plugin ignores existing Gradle practices. It has separate configuration DSL (instead of extending the test DSL), uses JavaExec task type (instead of Test task type) and misses Gradle's core events described above. As if neither Gradle nor JUnit team is willing to take the burden of providing proper integration.

Contributor

nskvortsov commented Oct 6, 2017

I don't understand, maybe I'm not familiar with the event model.

One can attach a TestListener or TestOutputListener for a single test task or globally. This allows ide/ci to receive and handle test events and data on-the-fly.

executing Junit 5 tests with gradle and seeing those results show up in your IDE? Is that a thing you can do?

Yes, you can (at least in IntelliJ). It is very useful when running a test also requires running other tasks (think of some kind of setup or code generation) defined in Gradle.

Overall, it feels like junit-platform-gradle-plugin ignores existing Gradle practices. It has separate configuration DSL (instead of extending the test DSL), uses JavaExec task type (instead of Test task type) and misses Gradle's core events described above. As if neither Gradle nor JUnit team is willing to take the burden of providing proper integration.

@Lizard

This comment has been minimized.

Show comment
Hide comment
@Lizard

Lizard Oct 6, 2017

@nskvortsov

As if neither Gradle nor JUnit team is willing to take the burden of providing proper integration.

From reading this discussion, I actually get the feeling that the JUnit guys have been quite open and willing to do their part, but simply were never requested: https://discuss.gradle.org/t/core-support-for-junit-platform-a-k-a-junit-5/19487

However, I think pointing fingers is a bit beside the point. For my part, I am just looking forward to getting proper JUnit 5 support into Gradle and using both how they are meant to be used :)

Lizard commented Oct 6, 2017

@nskvortsov

As if neither Gradle nor JUnit team is willing to take the burden of providing proper integration.

From reading this discussion, I actually get the feeling that the JUnit guys have been quite open and willing to do their part, but simply were never requested: https://discuss.gradle.org/t/core-support-for-junit-platform-a-k-a-junit-5/19487

However, I think pointing fingers is a bit beside the point. For my part, I am just looking forward to getting proper JUnit 5 support into Gradle and using both how they are meant to be used :)

@nskvortsov

This comment has been minimized.

Show comment
Hide comment
@nskvortsov

nskvortsov Oct 6, 2017

Contributor

@Lizard

using both how they are meant to be used

That would be awesome!

Contributor

nskvortsov commented Oct 6, 2017

@Lizard

using both how they are meant to be used

That would be awesome!

@jorn86

This comment has been minimized.

Show comment
Hide comment
@jorn86

jorn86 Oct 6, 2017

I don't think this has anything to do with IDE integration. The buildscan is the thing published to the gradle server with reporting build performance/ect..

I'm sorry. I was referring to the system which allows IDEs to pick up events sent from JUnit in order to display a nice overview. Apparently that's a different system then. Anyway, still important, but the rest of your and @nskvortsov comments seem to cover that.

jorn86 commented Oct 6, 2017

I don't think this has anything to do with IDE integration. The buildscan is the thing published to the gradle server with reporting build performance/ect..

I'm sorry. I was referring to the system which allows IDEs to pick up events sent from JUnit in order to display a nice overview. Apparently that's a different system then. Anyway, still important, but the rest of your and @nskvortsov comments seem to cover that.

@semoro

This comment has been minimized.

Show comment
Hide comment
@semoro

semoro Oct 16, 2017

Please, implement the full set of test selectors instead of limited to single pattern --tests way.

Like it can be passed in CLI Runner of JUnit

This required for launching tests fast and predictable form CLI.

And from Gradle Tooling API
Like in JUnit Gradle plugin

This required to make possible IDE(Such as IntelliJ) select tests properly.

semoro commented Oct 16, 2017

Please, implement the full set of test selectors instead of limited to single pattern --tests way.

Like it can be passed in CLI Runner of JUnit

This required for launching tests fast and predictable form CLI.

And from Gradle Tooling API
Like in JUnit Gradle plugin

This required to make possible IDE(Such as IntelliJ) select tests properly.

@serandel

This comment has been minimized.

Show comment
Hide comment
@serandel

serandel Oct 18, 2017

Do we have an (at least approximate) release date on this? I'm baffled that JUnit 5 and Gradle don't play well together, being both so widely used.

I would gladly donate some cash to a crowdfunding if it helped to prioritize this.

Do we have an (at least approximate) release date on this? I'm baffled that JUnit 5 and Gradle don't play well together, being both so widely used.

I would gladly donate some cash to a crowdfunding if it helped to prioritize this.

@edeandrea

This comment has been minimized.

Show comment
Hide comment
@edeandrea

edeandrea Nov 20, 2017

I too am voting for native support, especially being able to separate tests between source sets (i.e. test/integTest/funcTest). Having a single execution point for this as provided by the JUnit plugin doesn't solve our company's needs.

I too am voting for native support, especially being able to separate tests between source sets (i.e. test/integTest/funcTest). Having a single execution point for this as provided by the JUnit plugin doesn't solve our company's needs.

@jorn86

This comment has been minimized.

Show comment
Hide comment
@jorn86

jorn86 Dec 15, 2017

Can we get an update on this? Last info was "not earlier than Gradle 4.4 (~December 2017)", and this doesn't seem to have made it into 4.4.

jorn86 commented Dec 15, 2017

Can we get an update on this? Last info was "not earlier than Gradle 4.4 (~December 2017)", and this doesn't seem to have made it into 4.4.

@eriwen

This comment has been minimized.

Show comment
Hide comment
Member

eriwen commented Dec 15, 2017

Yes, I shared an update on the JUnit 5 Epic here.

@oehme

This comment has been minimized.

Show comment
Hide comment
@oehme

oehme Feb 2, 2018

Member

Closing as we now have a good idea of how we want to go forward: Built-in support for JUnit 5, scheduled for Gradle 4.6. See the update on the epic.

Member

oehme commented Feb 2, 2018

Closing as we now have a good idea of how we want to go forward: Built-in support for JUnit 5, scheduled for Gradle 4.6. See the update on the epic.

@oehme oehme closed this Feb 2, 2018

@mkobit

This comment has been minimized.

Show comment
Hide comment
@mkobit

mkobit Feb 16, 2018

Contributor

I know Gradle 4.6 is coming out with support for JUnit 5, but I wanted to ask a question on this issue since it seems related to one of @ajoberstar goals from the design document and the comment (#946 (comment)) - how close is the test platform/framework part of Gradle to being pluggable with other test frameworks? For example, if I wanted to plug in pytest or nose for Python testing?

Contributor

mkobit commented Feb 16, 2018

I know Gradle 4.6 is coming out with support for JUnit 5, but I wanted to ask a question on this issue since it seems related to one of @ajoberstar goals from the design document and the comment (#946 (comment)) - how close is the test platform/framework part of Gradle to being pluggable with other test frameworks? For example, if I wanted to plug in pytest or nose for Python testing?

@oehme

This comment has been minimized.

Show comment
Hide comment
@oehme

oehme Feb 17, 2018

Member

We've learned a few lessons from JUnit 5 as well as some native test frameworks, so it's getting more generic. But making it public is not a priority yet. One thing that would help is if you tried out integrating with the internal API to find limitations for the framework you had in mind. We could use that information to drive public API decisions.

Member

oehme commented Feb 17, 2018

We've learned a few lessons from JUnit 5 as well as some native test frameworks, so it's getting more generic. But making it public is not a priority yet. One thing that would help is if you tried out integrating with the internal API to find limitations for the framework you had in mind. We could use that information to drive public API decisions.

@marcphilipp

This comment has been minimized.

Show comment
Hide comment
@marcphilipp

marcphilipp Feb 17, 2018

Member

Another possible integration path would be to write a JUnit TestEngine for pytest or nose and use Gradle's useJUnitPlatform() support. I assume for Python based testing frameworks, you'd like to specify a set of *.py files or directories containing *.py files. The JUnit Platform API supports files and directories via FileSelector and DirectorySelector, respectively. However, AFAIK all current Gradle APIs rely on Java classes.

Member

marcphilipp commented Feb 17, 2018

Another possible integration path would be to write a JUnit TestEngine for pytest or nose and use Gradle's useJUnitPlatform() support. I assume for Python based testing frameworks, you'd like to specify a set of *.py files or directories containing *.py files. The JUnit Platform API supports files and directories via FileSelector and DirectorySelector, respectively. However, AFAIK all current Gradle APIs rely on Java classes.

@JLLeitschuh

This comment has been minimized.

Show comment
Hide comment
@JLLeitschuh

JLLeitschuh Feb 20, 2018

Contributor

This is the only plugin I've been able to successfully use with python code/testing.
https://github.com/linkedin/pygradle

Contributor

JLLeitschuh commented Feb 20, 2018

This is the only plugin I've been able to successfully use with python code/testing.
https://github.com/linkedin/pygradle

@danwallach

This comment has been minimized.

Show comment
Hide comment
@danwallach

danwallach Feb 27, 2018

Kudos where kudos are due: I adopted JUnit5 because I liked its new features, but their Gradle plugin had ... issues. Today, I upgraded from Gradle 4.5 to 4.6rc2 and made the appropriate edits in my build.gradle file (deleting the org.junit.platform.gradle.plugin, adding the call to useJUnitPlatform()) and... everything worked properly! The tests ran. JaCoCo is working again. Life is good. Thanks!

Kudos where kudos are due: I adopted JUnit5 because I liked its new features, but their Gradle plugin had ... issues. Today, I upgraded from Gradle 4.5 to 4.6rc2 and made the appropriate edits in my build.gradle file (deleting the org.junit.platform.gradle.plugin, adding the call to useJUnitPlatform()) and... everything worked properly! The tests ran. JaCoCo is working again. Life is good. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment