cucumber-companion plugin for Gradle and Maven

[leonard84]

🤔 What's the problem you're trying to solve?

The documentation suggests to create a suite class, so that Gradle and Maven can find and run the cucumber .feature files. The downside of having a single suite to run all features, is that you can't run just one specific feature. You could create a one-to-one mapping of suite to feature, but that is tedious and error prone.

✨ What's your proposed solution?

Create a cucumber-companion plugin for Gradle and Maven, which generates suite companion files for .feature files automatically. This removes the tedium and offers a better experience for the end users.

Furthermore, it would make cucumber compatible with Gradle Enterprise's Test Distribution and Predictive Test Selection.

I've created a PoC and verified that it works well for Gradle. If you think this would be a worthwhile addition I'd offer to do the initial contribution for both of these plugins.

⛏ Have you considered any alternatives or workarounds?

None

📚 Any additional context?

N/A

[mpkorstanje]

With the cucumber-junit-platform-engine Cucumber supports the JUnit Platform. This means that through the JUnit Platform you can already discover, select and execute any or all Features, Scenarios and Example in files, directories, class path roots and resources, ect, ect. This should in theory be enough for any build tool or IDE to run anything from a single scenario in a file to every feature on the classpath.

Unfortunately Gradle uses a rather limited part of the JUnit Platform. The Suite class is a work around for this specific problem. And I don't see much value in a contribution that adds a workaround on top of another workaround. You should feel free of-course to publish this plugin on your own if you are inclined to do so.

But I do see that you are a software engineer at Gradle, perhaps you could direct your efforts towards improving support for the JUnit Platform in Gradle (https://github.com/gradle/gradle/issues/4773, https://github.com/gradle/gradle/issues/4912, https://github.com/gradle/gradle/issues/4252, https://github.com/gradle/gradle/issues/5678)? And while I don't know how Gradles predictive test selection works under the hood, I suspect that a similar effort could be made there.

For IDE's things are a bit trickier. The cucumber-eclipse plugin needs a lot of love. IDEA is stuck on using io.cucumber.core.cli.Main to run tests (https://youtrack.jetbrains.com/issue/IDEA-227508). I don't know the state of the art on VSCode. But ideally they'd use the FileSelector and ClasspathResourceSelector for feature file to implement context sensitive run buttons/gutter icons.

[leonard84]

I'm aware of the capabilities of the JUnit Platform and the current limited support it gets. This suggestion, while not the ideal solution, will improve the user experience across for Gradle and Maven, as well as the IDEs. It is several orders of magnitude simpler to implement than enhancing all the other tools. The reality is I only have a limited amount of time to spend on the topic of better cucumber support, and the alternative is to get no improvement at all.

If you are not interested in accepting these as contributions to the project, then we’ll consider publishing them as standalone plugins.

But I do see that you are a software engineer at Gradle, perhaps you could direct your efforts towards improving support for the JUnit Platform in Gradle

Yes I work at Gradle, but not on the Gradle Build Tool.

[mpkorstanje]

Ah. That is unfortunate. Perhaps you can flag this internally as a structural problem within Gradle. It is a rather sorry state of affairs that we have a common test platform but do not see it fully utilized in our build tools.

In the past there have been a few code generating plugins (e.g. temyers/cucumber-jvm-parallel-plugin) that were used to generate runner classes for parallel execution. These tend to be quite feature rich to gracefully work around the consequences of running cucumber multiple times. This is more complexity than I'd care to support.

Now it does seems to me that the primary beneficiaries of this plugin are Gradle Enterprise users, who can use it to work around a limitation in Gradle. So it seems only fair that Gradle carries the maintenance burden for this plugin. So I reckon you should consider publishing a standalone plugin.

[leonard84]

If anyone is interested you can find the plugins over at https://github.com/gradle/cucumber-companion