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
{{ message }}
This repository has been archived by the owner on May 28, 2019. It is now read-only.
Gherkin (or Cucumber) should provide a JSON schema to simplify validation of JSON formatter output by the different implementations. While the feature description (and examples) for JSON formatter output is useful, a more concise specification would be helpful.
NOTES:
I provided such a JSON schema for behave, a Python-based BDD framework similar to Cucumber/JBehave. While its JSON output is not 100% compatible to Gherkin/Cucumber, it might serve as starting point. If you are interested, look here.
One additional note, multi-line text like in doc_strings, descriptions, etc. should be either a string or a sequence of lines (array of strings). The latter improves readability in JSON. The JSON schema could support both (also for backward compatibility) with only minor additions needed in the JSON parser/reader part.
The text was updated successfully, but these errors were encountered:
This is a good idea. The next major version of Gherkin (Gherkin 3) will be a major rewrite that simplifies the reporting format a lot. I think we should wait to implement a schema until Gherkin 3. See discussions on the cukes-devs google group for details about Gherkin 3.
Gherkin (or Cucumber) should provide a JSON schema to simplify validation of JSON formatter output by the different implementations. While the feature description (and examples) for JSON formatter output is useful, a more concise specification would be helpful.
SEE ALSO:
NOTES:
I provided such a JSON schema for behave, a Python-based BDD framework similar to Cucumber/JBehave. While its JSON output is not 100% compatible to Gherkin/Cucumber, it might serve as starting point. If you are interested, look here.
One additional note, multi-line text like in doc_strings, descriptions, etc. should be either a string or a sequence of lines (array of strings). The latter improves readability in JSON. The JSON schema could support both (also for backward compatibility) with only minor additions needed in the JSON parser/reader part.
The text was updated successfully, but these errors were encountered: