BDD library for the pytest runner¶

http://img.shields.io/pypi/v/pytest-bdd-ng.svg

pytest-bdd-ng combine descriptive clarity of Gherkin language with power and fullness of pytest infrastructure. It enables unifying unit and functional tests, reduces the burden of continuous integration server configuration and allows the reuse of test setups.

Pytest fixtures written for unit tests can be reused for setup and actions mentioned in feature steps with dependency injection. This allows a true BDD just-enough specification of the requirements without obligatory maintaining any context object containing the side effects of Gherkin imperative declarations.

Why `NG` ?¶

The current pytest plugin for cucumber is pytest-bdd , a popular project with 1.2k stars and used in 3k public repos and maintained by the pytest community. The upstream open-cucumber project does not have an official python release, so the current cucumber specs include features not available in pytest-bdd . This project is an effort to bridge the gap and also make it easier for pytest users to access new cucumber features.

Feature	original	NG	Description
Official parser support	-	+	All features of Feature files are supported from the “box” (localisation, Rules, Examples, Data tables, etc.)
Steps definitions via Cucumber expressions	-	+	Easy migration between implementations
Reporting using Messages	-	+	Possible to use all collection of Cucumber community tools for reporting
Pickles internal protocol	-	+	Allows to implement parsers based on other file types/principles
Heuristic step matching	-/+	+	Steps ease of use / amount of needed boilerplate code
Step execution context. Step types and variants of definition	-/+	+	Dispatching steps by kind. Steps injecting multiple fixtures. Default injecting behaviors. Steps could be used on import automatically. It’s possible to define default values for step variables.
Automatic collection of Feature files	-	+	No boilerplate code / No mix between steps definition and feature files
Load of Feature files by HTTP	-	+	Allows to integrate the library into external Feature storages
Stability and bugfixes	+	+/-
Supported python/pytest versions	+/-	+	NG supports wider and elder pytest&python version. Tested also for PyPy
Active community	+	-/+

Install pytest-bdd-ng¶

pip install pytest-bdd-ng

Compatibility policy¶

Supported Python/pytest pairs include all pairs allowed by pytest compatibility constraints within project support floors.
Supported Python range: 3.10-3.14.
Supported pytest range: >=6.2.5.
Python 3.9 and pytest <6.2.5 are EOL and are treated as unsupported.
To inspect or validate a pair locally, use:

compatibility_matrix --list --compatible-only
compatibility_matrix --python 310 --pytest 625
compatibility_matrix --python 314 --pytest 90

Packages for reporting¶

npm install @cucumber/html-formatter

TLDR;¶

Feature: Simplest example
  Scenario:
    # https://cucumber.io/docs/gherkin/reference/
    Given File "Passing.feature" with content:
      """gherkin
      Feature: Passing feature
        Scenario: Passing scenario
          * Passing step
      """
    # https://docs.pytest.org/en/stable/reference/fixtures.html#conftest-py-sharing-fixtures-across-multiple-files
    And File "conftest.py" with content:
      """python
      from pytest_bdd import step

      @step('Passing step')
      def _():
        ...
      """
    # https://docs.pytest.org/en/stable/how-to/usage.html
    When run pytest
    Then pytest outcome must contain tests with statuses:
      |passed|
      |     1|

Project layout¶

pytest-bdd-ng automatically collects *.feature files from pytest tests directory. Important to remember, that feature files are used by other team members as live documentation, so it’s not a very good idea to mix documentation and test code.

The more features and scenarios you have, the more important becomes the question about their organization. So the recommended way is to organize your feature files in the folders by semantic groups:

features
├──frontend
│  └──auth
│     └──login.feature
└──backend
   └──auth
      └──login.feature

And tests for these features would be organized in the following manner:

tests
└──conftest.py
└──functional
│     └──__init__.py
│     └──conftest.py
│     │     └── "User step library used by descendant tests"
│     │
│     │         from steps.auth.given import *
│     │         from steps.auth.when import *
│     │         from steps.auth.then import *
│     │
│     │         from steps.order.given import *
│     │         from steps.order.when import *
│     │         from steps.order.then import *
│     │
│     │         from steps.browser.given import *
│     │         from steps.browser.when import *
│     │         from steps.browser.then import *
│     │
│     └──frontend_auth.feature -> ../../features/frontend/auth.feature
│     └──backend_auth.feature -> ../../features/backend/auth.feature
...

The step definitions would then be organized like this:

steps
└──auth
│     └── given.py
│     │      └── """User auth step definitions"""
│     │          from pytest import fixture
│     │          from pytest_bdd import given, when, then, step
│     │
│     │          @fixture
│     │          def credentials():
│     │             return 'test_login', 'test_very_secure_pass'
│     │
│     │          @given('User login into application')
│     │          def user_login(credentials):
│     │             ...
│     └── when.py
│     └── then.py
└──order
│     └── given.py
│     └── when.py
│     └── then.py
└──browser
│     └── ...
...

To make links between feature files at features directory and test directory there are few options (for more information please examine the project’s tests):

Symlinks
.desktop files
.webloc files
.url files

Note

Link files also could be used to load features by http://

How to Contribute¶

The project is now open to contributions. Please open an issue for more details.

Features = .. NOTE:: Features below are part of executable documentation; user-facing usage

scenarios are expected to live under features/ so users can learn library behavior without inspecting tests/. Naming convention: use descriptive Title Case *.feature.md files and keep conversion traceability in specs/001-add-py314-pytest39-support/conversion-parity-audit.md. Markdown lint and pre-commit checks must pass for converted feature documentation before commit.

Tutorial¶

Feature: Simple project tests that use pytest-bdd-ng could be run via pytest
- Scenario: Catalog example with simplest steps

Step definition¶

Parameters¶

Step¶

Scenario¶

Outline¶

Feature: Scenario Outline examples could be tagged

Report¶

Feature:

Feature¶

Load¶

StructBDD¶

Advanced Features¶

Hooks¶

Note

Important difference from pytest-bdd

pytest-bdd-ng exposes several pytest hooks which might be helpful building useful reporting, visualization, etc on top of it:

pytest_bdd_before_scenario(request, feature, scenario) - Called before scenario is executed
pytest_bdd_run_scenario(request, feature, scenario) - Execution scenario protocol
pytest_bdd_after_scenario(request, feature, scenario) - Called after scenario is executed (even if one of steps has failed)
pytest_bdd_before_step(request, feature, scenario, step, step_func) - Called before step function is executed and it’s arguments evaluated
pytest_bdd_run_step(request, feature, scenario, step, previous_step) - Execution step protocol
pytest_bdd_before_step_call(request, feature, scenario, step, step_func, step_func_args) - Called before step function is executed with evaluated arguments
pytest_bdd_after_step(request, feature, scenario, step, step_func, step_func_args) - Called after step function is successfully executed
pytest_bdd_step_error(request, feature, scenario, step, step_func, step_func_args, exception) - Called when step function failed to execute
pytest_bdd_step_func_lookup_error(request, feature, scenario, step, exception) - Called when step lookup failed
pytest_bdd_match_step_definition_to_step(request, feature, scenario, step, previous_step) - Called to match step to step definition
pytest_bdd_get_step_caller(request, feature, scenario, step, step_func, step_func_args, step_definition) - Called to get step caller. For example could be used to make steps async
pytest_bdd_get_step_dispatcher(request, feature, scenario) - Provide alternative approach to execute scenario steps

Compatibility policy¶

Compatibility coverage is driven by pytest-to-python compatibility rules and bounded by project support floors. Supported Python range is 3.10-3.14 and supported pytest range is >=6.2.5. Python 3.9 and pytest <6.2.5 are EOL and explicitly unsupported.

compatibility_matrix --list --compatible-only
compatibility_matrix --python 310 --pytest 625
compatibility_matrix --python 314 --pytest 90

Executable usage documentation¶

User-facing end-to-end usage scenarios are documented in features/ and intended to be readable without browsing implementation tests.

compatibility_matrix --report-e2e-migration-threshold

Default steps¶

Here is the list of steps that are implemented inside of the pytest-bdd:

given

trace - enters the pdb debugger via pytest.set_trace()

when

trace - enters the pdb debugger via pytest.set_trace()

then

trace - enters the pdb debugger via pytest.set_trace()

Fixtures¶

pytest-bdd-ng exposes several plugin fixtures to give more testing flexibility

bdd_example - The current scenario outline parametrization.
attach - Fixture to allow attach files to Gherkin report
parameter_type_registry - Contains registry of user-defined types used in Cucumber expressions
step_registry - Contains registry of all user-defined steps
step_matcher- Contains matcher to help find step definition for selected step of scenario
steps_left - Current scenario steps left to execute; Allow inject steps to execute:

from collections import deque

from pytest_bdd.model import UserStep
from pytest_bdd import when

@when('I inject step "{keyword}" "{step_text}')
def inject_step(steps_left: deque, keyword, step_text, scenario):
    steps_left.appendleft(UserStep(text=step_text, keyword=keyword, scenario=scenario))

StructBDD¶

Gherkin itself isn’t a perfect tool to describe complex Data Driven Scenarios with alternative paths to execute test. For example it doesn’t support next things:

Few backgrounds per scenario
Alternative flows for scenario to setup same state
Alternative flows to describe same behavior defined by different steps
Usage of parameters inside Backgrounds
Joining of parameter tables, so full Cartesian product of parameters has to be listed in Examples
Example tables on different scenario levels

For such scenarios StructBDD DSL was developed. It independent on underlying data format, but supports most common formats for DSL development: YAML, Hocon, TOML, JSON5, HJSON out the box.

Steps could be defined as usual, and scenarios have different options. Let see.

steps.bdd.yaml

Name: Steps are executed one by one
Description: |
    Steps are executed one by one. Given and When sections
    are not mandatory in some cases.
Steps:
    - Step:
        Name: Executed step by step
        Description: Scenario description
        Steps:
            - I have a foo fixture with value "foo"
            - And: there is a list
            - When: I append 1 to the list
            - Step:
                Action: I append 2 to the list
                Type: And
            - Alternative:
                - Step:
                    Steps:
                        - And: I append 3 to the list
                        - Then: foo should have value "foo"
                        - But: the list should be [1, 2, 3]
                - Step:
                    Steps:
                        - And: I append 4 to the list
                        - Then: foo should have value "foo"
                        - But: the list should be [1, 2, 4]

Alternative steps produce separate test launches for every of flows. If alternative steps are defined on different levels - there would be Cartesian product of tests for every alternative step.

Scenario could be imported as usual, but with specified parser:

from textwrap import dedent
from pytest_bdd import given, when, then, scenario
from pytest_bdd.parser import StructBDDParser
from functools import partial

kind = StructBDDParser.KIND.YAML

@scenario(f"steps.bdd.{kind}", "Executed step by step", parser=partial(StructBDDParser, kind=kind)
def test_steps(feature):
    pass

Another option is to inject built scenario directly:

from pytest_bdd.struct_bdd.model import Step, Table

test_cukes = Step(
    name="Examples are substituted",
    steps=[
        Step(type='Given', action='I have <have> cucumbers'),
        Step(type='And', action='I eat <eat> cucumbers'),
        Step(type='Then', action='I have <left> cucumbers')
    ],
    examples=[
        Table(
            parameters=['have', 'eat', 'left'],
            values=[
                ['12', 5, 7.0],
                ["8.0", 3.0, "5"]
            ]
        )
    ]
)

There is also an option to build Step from dict(and use your own file format/preprocessor)

from pytest_bdd.struct_bdd.model import Step

cukes = Step.parse_obj(
        dict(
            Name="Examples are substituted",
            Steps=[
                dict(Given='I have <have> cucumbers'),
                dict(And='I eat <eat> cucumbers'),
                dict(Then='I have <left> cucumbers')
            ],
            Examples=[
                dict(
                    Table=dict(
                        Parameters=['have', 'eat', 'left'],
                        Values=[
                            ['12', 5, 7.0],
                            ["8.0", 3.0, "5"]
                        ]
                    )
                )
            ]
        )
    )

@cukes
def test(feature:Feature, scenario):
    assert feature.name == "Examples are substituted"

Example tables could be joined:

Tags:
  - TopTag
Name: StepName
Action: "Do first <HeaderA>, <HeaderB>, <HeaderC>"
Examples:
  - Join:
    - Table:
        Tags:
          - ExampleTagA
        Parameters:
          [ HeaderA, HeaderB ]
        Values:
          - [ A1, B1]
          - [ A2, B2]
    - Table:
        Tags:
          - ExampleTagB
        Parameters:
          [ HeaderB, HeaderC ]
        Values:
          - [ B1, C1 ]
          - [ B2, C2 ]
          - [ B3, C3 ]
Steps: []

Install StructBDD:

pip install pytest-bdd-ng[struct_bdd]

Reporting¶

It’s important to have nice reporting out of your bdd tests. Cucumber introduced some kind of standard for json format which can be used for, for example, by this Jenkins plugin.

To have an output in json format:

pytest --cucumberjson=<path to json report>

This will output an expanded (meaning scenario outlines will be expanded to several scenarios) cucumber format.

To enable gherkin-formatted output on terminal, use

pytest -vv --gherkin-terminal-reporter

Allure reporting is also in place https://docs.qameta.io/allure and based on allure-pytest https://pypi.org/project/allure-pytest/ plugin. Usage is same.

To install plugin¶

pip install pytest-bdd-ng[allure]

Test code generation helpers¶

For newcomers it’s sometimes hard to write all needed test code without being frustrated. To simplify their life, simple code generator was implemented. It allows to create fully functional but of course empty tests and step definitions for given a feature file. It’s done as a separate console script provided by pytest-bdd package:

pytest --generate --feature <feature file name> .. <feature file nameN>

It will print the generated code to the standard output so you can easily redirect it to the file:

pytest --generate --feature features/some.feature > tests/functional/test_some.py

Advanced code generation¶

For more experienced users, there’s smart code generation/suggestion feature. It will only generate the test code which is not yet there, checking existing tests and step definitions the same way it’s done during the test execution. The code suggestion tool is called via passing additional pytest arguments:

pytest --generate-missing --feature features tests/functional

The output will be like:

============================= test session starts ==============================
platform linux2 -- Python 2.7.6 -- py-1.4.24 -- pytest-2.6.2
plugins: xdist, pep8, cov, cache, bdd, bdd, bdd
collected 2 items

Scenario is not bound to any test: "Code is generated for scenarios which are not bound to any tests" in feature "Missing code generation" in /tmp/pytest-552/testdir/test_generate_missing0/tests/generation.feature
--------------------------------------------------------------------------------

Step is not defined: "I have a custom bar" in scenario: "Code is generated for scenario steps which are not yet defined(implemented)" in feature "Missing code generation" in /tmp/pytest-552/testdir/test_generate_missing0/tests/generation.feature
--------------------------------------------------------------------------------
Please place the code above to the test file(s):

@scenario('tests/generation.feature', 'Code is generated for scenarios which are not bound to any tests')
def test_Code_is_generated_for_scenarios_which_are_not_bound_to_any_tests():
    """Code is generated for scenarios which are not bound to any tests."""


@given("I have a custom bar")
def I_have_a_custom_bar():
    """I have a custom bar."""

As as side effect, the tool will validate the files for format errors, also some of the logic bugs, for example the ordering of the types of the steps.

Known limitations¶

Unable fully collect messages report if tests were launched using xdist plugin

Authors¶

Oleg Pidsadnyi: original idea, initial implementation and further improvements
Anatoly Bubenkov: key implementation idea and realization, many new features and improvements

These people have contributed to pytest-bdd, in alphabetical order:

MIT License¶

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Changelog¶

Planned¶

Refactor
- Split plugins
  - Add poset plugin/hooks ordering into pluggy library
- Simplify complex code chunks
  - Rework extended_step_context method usage
- Hide traceback for pytest code “__tracebackhide__ = True”
- Allure plugin integration
  - Investigate messages -> cucumber/junit-xml-formatter -> allure
  - Implement direct messages -> allure
  - Check newest allure-reporting plugin for reporting
    - pytest
    - messages
  - Implement allure-formater to convert messages into allure report
- Code generation
  - Generate code into dir structure aligned with proposed project layout
  - Code generation must patch existing conftest/test files for generated tests
  - Features parameter must not be specified. Code must be generated for imported features
    - Rework generation code to include new features directly
  - Remove dependency on pydantic where possible
- Documentation generation
  - Use modern tools; Don’t use multiple templating tools
  - Include StructBDD support
  - Add API doc
  - Move tox.ini, pytest.ini into pyproject.toml
  - Generate documentation via https://github.com/jolly-good-toolbelt/sphinx_gherkindoc instead of direct use
    - Move sphinx-gherkindoc to official parser - Documentation is ugly when contains injected code
Review report generation to be conform with official tools
Support of messages:
- Check official cucumber-messages full support; Some items were added
- Pending:
  - parse_error
  - undefined_parameter_type
Add mode to execute scenarios with missing/failing steps
- Ambiguous steps must be handled
- Undefined steps must be handled
Tests rework
- Try to use pytest-xdist at workers on different machines (sending back ndjson info https://codespeak.net/execnet/example/test_info.html#sending-channels-over-channels)
  - Investigate https://smarie.github.io/python-pytest-harvest/
- Check support of pytest-rerunfailures
- Parametrize step execution by different step realizations using https://smarie.github.io/python-pytest-cases/
- Add tests about linked files and features autoload (feature autoload must not be disabled on linked files)
- Remove tests targeting Feature parsing
  - https://github.com/pytest-dev/pytest-bdd/issues/488
- Add support of native legacy cucumber-json
- Switch testdir to pytester after pytest<6.2 get EOL (python 3.9 get EOL)
Use uv/ruff
- Use mypy on ci, pyright on-commit

Unreleased¶

Internal: package functions were split between plugins
Unify paths globbing between generation and autoloading
Ruff is used for code formatting and linting
Official gherkin parser support =33
Official cucumber-messages package is used for messages reporting
- cucumber-messages has accepted by gherkin community
Temporarily allure reporting is disabled
Switched *.md support to native realization
Declined usage of pytest<6.0
StructBDD features autoload is checked and uses common mechanism
- Features are collected by their mimetype

2.4.0¶

Add python official gherkin parser for markdown documents

2.3.1¶

Fixup documentation generation

2.3.0¶

Add mobile readthedocs site support theme
Convert e2e test features definitions to markdown
Implement support of Markdown using js based parser
Update versions:
- Drop python 3.8
- Add python 3.13
- Drop pytest<5.2
Added dummy html reporter
Fixed pytest.ini non-working option “disable_feature_autoload”
Improved fixture injection by adding seamless fixtures on plugin/module collection

2.2.0¶

Move documentation to Gherkin itself
Fixed pytest.ini option “disable_feature_autoload”
Improved fixture injection by adding seamless fixtures on plugin/module collection

2.1.4¶

Add support for Python 3.12 in CI
Add support for pytest 8
Switch to the official Gherkin package: https://pypi.org/project/ci-environment/
Fix other compatibility issues

2.1.0¶

Add validation for legacy cucumber.json output
Migrated to Pydantic 2
Add tests for PyPy
Using tox4
Added support of conditional hooks https://cucumber.io/docs/cucumber/api/?lang=java#conditional-hooks
Support of messages:
- Done:
  - meta
  - gherkin_document
  - pickle
  - source
  - step_definition
  - test_case
  - test_case_finished
  - test_case_started
  - test_run_finished
  - test_run_started
  - test_step_finished
  - test_step_started
  - parameter_type
  - attachment
  - hook

2.0.0¶

Reviewed StructBdd step collection; no more as_test / as_test_decorator Step methods are needed directly used
Drop python 3.7
Move StructBDD model to Pydantic
Remove ast module usage by StructBDD
Test filters in scenario/scenarios to filter out not needed scenarios
.url, .desktop and .webloc files are collected from test directories, so scenario/scenarios usages is not necessary
Load features/scenarios by url
Features are autoloaded by default; Feature autoload could be disabled by --disable-feature-autoload cli option
Relative feature paths are counted from pytest rootpath
No more injection of tests into module space; Tests have to be registered directly
Separate generation scripts were moved to pytest environment
scenario no more override collected scenarios; They have to be registered independently. Scenarios could be filtered out if needed.
Added support of messages
Added support of cucumber expressions https://github.com/cucumber/cucumber-expressions#readme
It possible to name anonymous groups during step parsing
Remove legacy feature parser (and surplus features of it)
Remove outdated migration script

1.2.3¶

Features could be autoloaded by –feature-autoload cli option
Remove possibility to manually register imported steps; They are registered automatically

1.2.2¶

Add possibility to register imported steps

1.2.0¶

Make liberal step definitions conform with
- Change messages and Gherkin parser/pickle compiler to retain step keyword (#1741)
- Proposal: Unambiguous Keywords (#768)

1.1.2¶

Fixups

1.1.1¶

Added hook to alter scenario steps execution protocol

1.1.0¶

Added allure plugin extension for allure-pytest
Added StructBDD DSL

1.0.0¶

Default step parameter parser is switched to cfparse. String step name is compiled to cfparse
Step functions could get compiled instances of parse, cfparse and re.compile directly
Drop pytest 4
Drop python 3.6
Added tags support for Examples sections for original parser
Added joining by parameters between examples sections on different levels (and with fixtures) for original feature parser
Step could override multiple fixtures using target_fixtures parameter
Default step parameters injection as fixtures behavior could be changed by params_fixtures_mapping step parameter
Step definitions can have “yield” statements again (4.0 release broke it). They will be executed as normal fixtures: code after the yield is executed during teardown of the test. (youtux)
Show pass/fail status per step in Gherkin terminal reporter
Step definitions could be used independently from keyword by step decorator
- https://github.com/pytest-dev/pytest-bdd/issues/450
pytest_bdd_apply_tag was removed; pytest_bdd_convert_tag_to_marks was added instead
Feature parser switched to official one
- https://github.com/pytest-dev/pytest-bdd/issues/394
- https://github.com/pytest-dev/pytest-bdd/issues/511
Changes scenario and scenarios function/decorator feature registration order. Both could be used as decorators
Move scenario execution & step matching to hooks
Added possibility to operate steps stack via fixture
Other

Pre pytest-bdd-ng era¶

5.0.0¶

This release introduces breaking changes, please refer to the Migration from 4.x.x.

Rewrite the logic to parse Examples for Scenario Outlines. Now the substitution of the examples is done during the parsing of Gherkin feature files. You won’t need to define the steps twice like @given("there are <start> cucumbers") and @given(parsers.parse("there are {start} cucumbers")). The latter will be enough.
Removed example_converters from scenario(...) signature. You should now use just the converters parameter for given, when, then.
Removed --cucumberjson-expanded and --cucumber-json-expanded options. Now the JSON report is always expanded.
Removed --gherkin-terminal-reporter-expanded option. Now the terminal report is always expanded.

4.1.0¶

when and then steps now can provide a target_fixture, just like given does. Discussion at https://github.com/pytest-dev/pytest-bdd/issues/402.
Drop compatibility for python 2 and officially support only python >= 3.6.
Fix error when using –cucumber-json-expanded in combination with example_converters (marcbrossaissogeti).
Fix –generate-missing not correctly recognizing steps with parsers

4.0.2¶

Fix a bug that prevents using comments in the Examples: section. (youtux)

4.0.1¶

Fixed performance regression introduced in 4.0.0 where collection time of tests would take way longer than before. (youtux)

4.0.0¶

This release introduces breaking changes, please refer to the Migration from 3.x.x.

Strict Gherkin option is removed (@scenario() does not accept the strict_gherkin parameter). (olegpidsadnyi)
@scenario() does not accept the undocumented parameter caller_module anymore. (youtux)
Given step is no longer a fixture. The scope parameter is also removed. (olegpidsadnyi)
Fixture parameter is removed from the given step declaration. (olegpidsadnyi)
pytest_bdd_step_validation_error hook is removed. (olegpidsadnyi)
Fix an error with pytest-pylint plugin #374. (toracle)
Fix pytest-xdist 2.0 compatibility #369. (olegpidsadnyi)
Fix compatibility with pytest 6 --import-mode=importlib option. (youtux)

3.4.0¶

Parse multiline steps according to the gherkin specification #365.

3.3.0¶

Drop support for pytest < 4.3.
Fix a Python 4.0 bug.
Fix pytest --generate-missing functionality being broken.
Fix problematic missing step definition from strings containing quotes.
Implement parsing escaped pipe characters in outline parameters (Mark90) #337.
Disable the strict Gherkin validation in the steps generation (v-buriak) #356.

3.2.1¶

Fix regression introduced in 3.2.0 where pytest-bdd would break in presence of test items that are not functions.

3.2.0¶

Fix Python 3.8 support
Remove code that rewrites code. This should help with the maintenance of this project and make debugging easier.

3.1.1¶

Allow unicode string in @given() step names when using python2. This makes the transition of projects from python 2 to 3 easier.

3.1.0¶

Drop support for pytest < 3.3.2.
Step definitions generated by $ pytest-bdd generate will now raise NotImplementedError by default.
@given(...) no longer accepts regex objects. It was deprecated long ago.
Improve project testing by treating warnings as exceptions.
pytest_bdd_step_validation_error will now always receive step_func_args as defined in the signature.

3.0.2¶

Add compatibility with pytest 4.2 (sliwinski-milosz) #288.

3.0.1¶

Minimal supported version of pytest is now 2.9.0 as lower versions do not support bool type ini options (sliwinski-milosz) #260
Fix RemovedInPytest4Warning warnings (sliwinski-milosz) #261.

3.0.0¶

Fixtures pytestbdd_feature_base_dir and pytestbdd_strict_gherkin have been removed. Check the Migration of your tests from versions 2.x.x for more information (sliwinski-milosz) #255
Fix step definitions not being found when using parsers or converters after a change in pytest (youtux) #257

2.21.0¶

Gherkin terminal reporter expanded format (pauk-slon)

2.20.0¶

Added support for But steps (olegpidsadnyi)
Fixed compatibility with pytest 3.3.2 (olegpidsadnyi)
MInimal required version of pytest is now 2.8.1 since it doesn’t support earlier versions (olegpidsadnyi)

2.19.0¶

Added –cucumber-json-expanded option for explicit selection of expanded format (mjholtkamp)
Step names are filled in when –cucumber-json-expanded is used (mjholtkamp)

2.18.2¶

Fix check for out section steps definitions for no strict gherkin feature

2.18.1¶

Relay fixture results to recursive call of ‘get_features’ (coddingtonbear)

2.18.0¶

Add gherkin terminal reporter (spinus + thedrow)

2.17.2¶

Fix scenario lines containing an @ being parsed as a tag. (The-Compiler)

2.17.1¶

Add support for pytest 3.0

2.17.0¶

Fix FixtureDef signature for newer pytest versions (The-Compiler)
Better error explanation for the steps defined outside of scenarios (olegpidsadnyi)
Add a pytest_bdd_apply_tag hook to customize handling of tags (The-Compiler)
Allow spaces in tag names. This can be useful when using the pytest_bdd_apply_tag hook with tags like @xfail: Some reason.

2.16.1¶

Cleaned up hooks of the plugin (olegpidsadnyi)
Fixed report serialization (olegpidsadnyi)

2.16.0¶

Fixed deprecation warnings with pytest 2.8 (The-Compiler)
Fixed deprecation warnings with Python 3.5 (The-Compiler)

2.15.0¶

Add examples data in the scenario report (bubenkoff)

2.14.5¶

Properly parse feature description (bubenkoff)

2.14.3¶

Avoid potentially random collection order for xdist compartibility (bubenkoff)

2.14.1¶

Pass additional arguments to parsers (bubenkoff)

2.14.0¶

Add validation check which prevents having multiple features in a single feature file (bubenkoff)

2.13.1¶

Allow mixing feature example table with scenario example table (bubenkoff, olegpidsadnyi)

2.13.0¶

Feature example table (bubenkoff, sureshvv)

2.12.2¶

Make it possible to relax strict Gherkin scenario validation (bubenkoff)

2.11.3¶

Fix minimal six version (bubenkoff, dustinfarris)

2.11.1¶

Mention step type on step definition not found errors and in code generation (bubenkoff, lrowe)

2.11.0¶

Prefix step definition fixture names to avoid name collisions (bubenkoff, lrowe)

2.10.0¶

Make feature and scenario tags to be fully compartible with pytest markers (bubenkoff, kevinastone)

2.9.1¶

Fixed FeatureError string representation to correctly support python3 (bubenkoff, lrowe)

2.9.0¶

Added possibility to inject fixtures from given keywords (bubenkoff)

2.8.0¶

Added hook before the step is executed with evaluated parameters (olegpidsadnyi)

2.7.2¶

Correct base feature path lookup for python3 (bubenkoff)

2.7.1¶

Allow to pass scope for given steps (bubenkoff, sureshvv)

2.7.0¶

Implemented scenarios shortcut to automatically bind scenarios to tests (bubenkoff)

2.6.2¶

Parse comments only in the beginning of words (santagada)

2.6.1¶

Correctly handle pytest-bdd command called without the subcommand under python3 (bubenkoff, spinus)
Pluggable parsers for step definitions (bubenkoff, spinus)

2.5.3¶

Add after scenario hook, document both before and after scenario hooks (bubenkoff)

2.5.2¶

Fix code generation steps ordering (bubenkoff)

2.5.1¶

Fix error report serialization (olegpidsadnyi)

2.5.0¶

Fix multiline steps in the Background section (bubenkoff, arpe)
Code cleanup (olegpidsadnyi)

2.4.5¶

Fix unicode issue with scenario name (bubenkoff, aohontsev)

2.4.3¶

Fix unicode regex argumented steps issue (bubenkoff, aohontsev)
Fix steps timings in the json reporting (bubenkoff)

2.4.2¶

Recursion is fixed for the –generate-missing and the –feature parameters (bubenkoff)

2.4.1¶

Better reporting of a not found scenario (bubenkoff)
Simple test code generation implemented (bubenkoff)
Correct timing values for cucumber json reporting (bubenkoff)
Validation/generation helpers (bubenkoff)

2.4.0¶

Background support added (bubenkoff)
Fixed double collection of the conftest files if scenario decorator is used (ropez, bubenkoff)

2.3.3¶

Added timings to the cucumber json report (bubenkoff)

2.3.2¶

Fixed incorrect error message using e.argname instead of step.name (hvdklauw)

2.3.1¶

Implemented cucumber tags support (bubenkoff)
Implemented cucumber json formatter (bubenkoff, albertjan)
Added ‘trace’ keyword (bubenkoff)

2.1.2¶

Latest pytest compartibility fixes (bubenkoff)

2.1.1¶

Bugfixes (bubenkoff)

2.1.0¶

Implemented multiline steps (bubenkoff)

2.0.1¶

Allow more than one parameter per step (bubenkoff)
Allow empty example values (bubenkoff)

2.0.0¶

Pure pytest parametrization for scenario outlines (bubenkoff)
Argumented steps now support converters (transformations) (bubenkoff)
scenario supports only decorator form (bubenkoff)
Code generation refactoring and cleanup (bubenkoff)

1.0.0¶

Implemented scenario outlines (bubenkoff)

0.6.11¶

Fixed step arguments conflict with the fixtures having the same name (olegpidsadnyi)

0.6.9¶

Implemented support of Gherkin “Feature:” (olegpidsadnyi)

0.6.8¶

Implemented several hooks to allow reporting/error handling (bubenkoff)

0.6.6¶

Fixes to unnecessary mentioning of pytest-bdd package files in py.test log with -v (bubenkoff)

0.6.5¶

Compatibility with recent pytest (bubenkoff)

0.6.4¶

More unicode fixes (amakhnach)

0.6.3¶

Added unicode support for feature files. Removed buggy module replacement for scenario. (amakhnach)

0.6.2¶

Removed unnecessary mention of pytest-bdd package files in py.test log with -v (bubenkoff)

0.6.1¶

Step arguments in whens when there are no given arguments used. (amakhnach, bubenkoff)

0.6.0¶

Added step arguments support. (curzona, olegpidsadnyi, bubenkoff)
Added checking of the step type order. (markon, olegpidsadnyi)

0.5.2¶

Added extra info into output when FeatureError exception raises. (amakhnach)

0.5.0¶

Added parametrization to scenarios
Coveralls.io integration
Test coverage improvement/fixes
Correct wrapping of step functions to preserve function docstring

0.4.7¶

Fixed Python 3.3 support

0.4.6¶

Fixed a bug when py.test –fixtures showed incorrect filenames for the steps.

0.4.5¶

Fixed a bug with the reuse of the fixture by given steps being evaluated multiple times.

0.4.3¶

Update the license file and PYPI related documentation.

BDD library for the pytest runner¶

Why NG ?¶

Install pytest-bdd-ng¶

Compatibility policy¶

Packages for reporting¶

TLDR;¶

Project layout¶

How to Contribute¶

Tutorial¶

Step definition¶

Parameters¶

Step¶

Scenario¶

Outline¶

Report¶

Feature¶

Load¶

StructBDD¶

Advanced Features¶

Hooks¶

Compatibility policy¶

Executable usage documentation¶

Default steps¶

Fixtures¶

StructBDD¶

Reporting¶

To install plugin¶

Test code generation helpers¶

Advanced code generation¶

Known limitations¶

Authors¶

MIT License¶

Changelog¶

Planned¶

Unreleased¶

2.4.0¶

2.3.1¶

2.3.0¶

2.2.0¶

2.1.4¶

2.1.0¶

2.0.0¶

1.2.3¶

1.2.2¶

1.2.0¶

1.1.2¶

1.1.1¶

1.1.0¶

1.0.0¶

Pre pytest-bdd-ng era¶

5.0.0¶

4.1.0¶

4.0.2¶

4.0.1¶

4.0.0¶

3.4.0¶

3.3.0¶

3.2.1¶

3.2.0¶

3.1.1¶

3.1.0¶

3.0.2¶

3.0.1¶

3.0.0¶

2.21.0¶

2.20.0¶

2.19.0¶

2.18.2¶

2.18.1¶

2.18.0¶

2.17.2¶

2.17.1¶

2.17.0¶

2.16.1¶

2.16.0¶

2.15.0¶

2.14.5¶

2.14.3¶

2.14.1¶

2.14.0¶

Why `NG` ?¶