Skip to content
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

Cucumber Messages protocol #169

Open
tyranron opened this issue Nov 29, 2021 · 2 comments
Open

Cucumber Messages protocol #169

tyranron opened this issue Nov 29, 2021 · 2 comments
Labels
feature New feature or request k::api Related to API (application interface) k::UI/UX UI (user interface) and UX (user experience) changes postponed Postponed due to lack of implementation reasons rfc

Comments

@tyranron
Copy link
Member

Revealed from cucumber-rs/gherkin#28 (comment)

Cucumber Messages is a message protocol for representing results and other information from Cucumber - Replaces json and junit formatters.

Stability/Performance:

With Cucumber Messages, several messages containing smaller pieces of information are emitted continuously to a stream,
avoiding high memory consumption and enabling real-time processing of results.

Additional functionality (motivation):

The protocol aims to decouple various components of the Cucumber platform so that:

  • Each component only needs to know about a subset of messages

  • Gherkin is decoupled from the Cucumber execution component

    • This is part of a strategy to support other formats such as Markdown and Excel

@ilslv what do you think about this? We have the similar thing in our implementation, but hand-baked. Should we support it as a bare-bone of our implementation, or rather have just yet another Writer for it?

@tyranron tyranron added the enhancement Improvement of existing features or bugfix label Nov 29, 2021
@ilslv
Copy link
Member

ilslv commented Nov 30, 2021

@tyranron from what I can tell, we can easily support this with another Writer implementation, as we generate a lot more events, than just Test(Case/Step)(Started/Finished). Those additional events allow us to skip some parsing stuff, like we don't have to count finished Scenarios for particular Feature to be sure, that it's finished. We can just wait for the event::Feature::Finished.

But I would hold on implementing this feature for couple of reasons:

  • Despite protocol being 3 years old, I don't see tools adopting it. The only example I could find is official https://reports.cucumber.io
  • cucumber releases are quite hard to follow, so we will spent too much time supporting existing implementation

My proposal is to wait until more tools will support it or until users of this library will actually ask for it.

@tyranron
Copy link
Member Author

@ilslv

My proposal is to wait until more tools will support it or until users of this library will actually ask for it.

Or there will be a demand from library users for it.

@tyranron tyranron added postponed Postponed due to lack of implementation reasons rfc labels Nov 30, 2021
@tyranron tyranron added feature New feature or request k::UI/UX UI (user interface) and UX (user experience) changes k::api Related to API (application interface) and removed enhancement Improvement of existing features or bugfix labels Nov 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request k::api Related to API (application interface) k::UI/UX UI (user interface) and UX (user experience) changes postponed Postponed due to lack of implementation reasons rfc
Projects
None yet
Development

No branches or pull requests

2 participants