-
Notifications
You must be signed in to change notification settings - Fork 232
Description
Context
In previous versions of pytest-bdd, it was possible to define steps that included inline YAML-like syntax, which made it much easier to write complex or parameterized tests. For example:
Given a new resource with:
id: 1234
name: new resource
data: any-dataand then parse those parameters using a custom parser:
@given(parsers.cfparse(
'a new resource with:\n{resource_parameters:yaml}',
extra_types={"yaml": yaml.safe_load}
))
def _(resource_parameters):
id = resource_parameters["id"]
# test codeCurrent Problem
Since version 8 of pytest-bdd, it seems that changes introduced in the underlying Gherkin parser (via gherkin-official) have made this syntax invalid.
Running tests written this way now produces the following parser error:
.venv/lib/python3.10/site-packages/pytest_bdd/gherkin_parser.py:316: in get_gherkin_document
gherkin_data = Parser().parse(feature_file_text)
.venv/lib/python3.10/site-packages/gherkin/parser.py:79: in parse
state = self.match_token(state, token, context)
.venv/lib/python3.10/site-packages/gherkin/parser.py:222: in match_token
return state_map[state](token, context)
.venv/lib/python3.10/site-packages/gherkin/parser.py:1104: in match_token_at_15
self.add_error(context, error)
.venv/lib/python3.10/site-packages/gherkin/parser.py:97: in add_error
raise CompositeParserException(context.errors)
E gherkin.errors.CompositeParserException: Parser errors:
E (9:13): expected: #EOF, #TableRow, #DocStringSeparator, #StepLine, #TagLine, #ExamplesLine, #ScenarioLine, #RuleLine, #Comment, #Empty, got 'id: 1234'
Expected Behavior / Feature Proposal
It would be extremely helpful to support YAML-like syntax blocks inside Gherkin steps again — either through:
Allowing indentation-based content as a valid part of a step body,
Or by supporting a new syntax (e.g., fenced blocks or docstrings with a yaml type hint) that can be parsed using custom parameter types.
This feature would allow writing structured input directly in .feature files, while still enabling parameterization via Gherkin variables.
Motivation
YAML-style parameter blocks make test scenarios much more readable and maintainable, especially when working with APIs or data-rich test cases.
This capability was previously possible using cfparse with custom extra_types, and restoring it (or providing an alternative) would improve developer ergonomics significantly.
It would be important that any future implementation of this feature continues to support the use of Gherkin variables inside the YAML-like syntax, as this was previously a key advantage for writing parameterized and data-driven tests directly in feature files:
Given a new resource with:
id: <id>
Examples:
| id |Thank you in advance