A centralized features/ for each Cucumber implementation?

[Zearin]

( This is just a spur-of-the-moment thought I had. Request For Comments! ;) )

---

I like how cucumber/gherkin3 is organized: each implementation has its own repository, but the parent repository is where all the collaboration happens. This allows for some flexibility between the different Gherkin 3 implementations, but uses the centralization of the parent repository to prevent any significant divergence (including some that were proposed by me :P).

I think it also promotes cross-pollination between people who arrive from different implementations. When a user asks “Why X?” or “Why not Y?”, it’s easy to say “Because of the big picture Z”. (It’s much easier than saying “Go see «other repository»/«other issue»”. And from the user side of the fence, it also “feels” easier to receive this answer and see an issue from the _same) repository; the other implementations are right there in the parent repository, too, which is also nice.)

---

And now, the questions!

• (parent project) Would it be beneficial to organize the Cucumber projects similarly?
• (each implementation) What about a separate “cucumber-tests” project?
  
  I imagine something like the following:
  • This cucumber-tests project would contain features, but no step definitions
  • Each cucumber implementation would supply its own step definitions, and get tested against the features in cucumber-tests
  • Each implementation could (optionally) go further and provide its own features for the truly implementation-specific behaviors

---

I was browsing some of the features for the different cucumber implementations (in response to your good feedback on #8) when this occurred to me.

What do you think?

[jbpros]

Cucumber TCK is such a shared set of features (and step definitions) specifying the behaviour of any implementation of Cucumber. It was started in the early days of Cucumber.js and Cucumber-JVM.

The Cucumber-JVM project lost interest in the TCK but Cucumber.js is still running against the TCK feature suite. We recently merged the TCK features and step definitions into the Cucumber.js repo. The reason is that it was the only implementation still following TCK and we wanted the build toolchain to be simpler.

I still believe a shared feature suite is a great idea to help us keep a high-level perspective on the expected behaviour of Cucumbers.

I'd be more than happy to bring it back to life, if there is any interest. Should that happen, I think we should rework the language used in the feature suite.

[mattwynne]

Yeah I thought the TCK was a good idea in principle. My view of why the TCK never got taken up more widely was that the language in the scenarios was too coupled to the UI. Given what we know now, we'd want to make the effort to use domain language in the scenarios, and describe behaviour in terms that would be applicable to the core domain of any Cucumber implementation, as well as its UI.

[aslakhellesoy]

Let's bury the TCK and start from scratch

[Zearin]

Let's bury the TCK and start from scratch

👍

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs.

[stale]

This issue has been automatically closed because of inactivity. You can support the Cucumber core team on opencollective.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.