You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
tyranron opened this issue
Nov 29, 2021
· 2 comments
Labels
featureNew feature or requestk::apiRelated to API (application interface)k::UI/UXUI (user interface) and UX (user experience) changespostponedPostponed due to lack of implementation reasonsrfc
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?
The text was updated successfully, but these errors were encountered:
@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
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
featureNew feature or requestk::apiRelated to API (application interface)k::UI/UXUI (user interface) and UX (user experience) changespostponedPostponed due to lack of implementation reasonsrfc
Revealed from cucumber-rs/gherkin#28 (comment)
@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?The text was updated successfully, but these errors were encountered: