Q: why '@when' doesn't export target_fixture?

[bulletRush]

I am a newbie of pytest-bdd. I have a question about when decorator.
If we export 'target_fixture' args for 'when' decorator, we can rewrite

        @when('I eat <eat> cucumbers')
        def eat_cucumbers(start_cucumbers, eat):
            assert isinstance(eat, float)
            start_cucumbers['eat'] = eat


        @then('I should have <left> cucumbers')
        def should_have_left_cucumbers(start_cucumbers, start, eat, left):
            assert isinstance(left, str)
            assert start - eat == int(left)
            assert start_cucumbers['start'] == start
            assert start_cucumbers['eat'] == eat

to

        @when('I eat <eat> cucumbers', target_fixture='left')
        def eat_cucumbers(start, eat):
            assert isinstance(eat, float)
            left = start - eat
            return left


        @then('I should have <expect_left> cucumbers')
        def should_have_left_cucumbers(expect_left, left):
            assert expect_left == left

for real project test cases, this will make more easy for reusing those steps.
so why pytest-bdd does not export target_fixture for when decorator? should I make a MR for this change?

[nileshpandey3]

@bulletRush

• As per the official docs target_fixture is only available with the @given decorator , so for now you will have to use the way its available, unless they expand this to @when
• Docs: https://pytest-bdd.readthedocs.io/en/latest/index.html?highlight=target%20fixture#override-fixtures-via-given-steps

[mattelacchiato]

I've just struggled with the same issue. Since there doesn't seem to be an argument against an implementation, at least I would be very thankful for a MR @bulletRush ❤️

[youtux]

target_fixture is only available for "given" steps, and that's by design.

If you need the result of your step to be used somewhere else, then your step should probably be a "given".
"when" steps are supposed to execute actions, and this design encourages you to think which part of your scenario is part of the setup ("given" steps) vs what is the exercise ("when" steps) vs what is the assertion ("then" steps).

Although I wouldn't recommend it, if you really need to store the result of a step and reuse it somewhere else, you can always use a fixture like

@pytest.fixture
def context():
    return {}

and use its content in the "when" and "then" steps:

@when("something happens")
def when_something_happens(context):
    context['something_happened'] = True

@then("something should have happened")
def then_something_has_happened(context):
    assert context['something_happened'] is True

A PR that allows "when" steps to have a target_fixture parameter would probably be rejected unless there is a very good use case and motivation for it.

[1Mark]

@youtux the issue here is that pytest-bdd assumes you are not testing the return values of functions. The action in the when step can and often is a function that has a return value. How can you assert the return value in the then step?

Given I want to search for cake
When I send a GET request to https://google.co.uk with cake as the payload
Then I get a response with the corresponding HTML of the page

How would you test this? You need a way to cleanly pass the response from when to then.

Otherwise, people will be forced to skip when and just go straight use another given.

[youtux]

@pytest.fixture
def context():
    return {}

@given("I want to search for cake")
def i_want_to_search_for_cake(...):
    ...

@when(parsers.parse("I send a GET request to {url} with cake as the payload"))
def i_send_request_with_cacke_as_payload(context, http_client, method, url):
    context["response"] = http_client.get(url, {"cake": "a cake"})

@then("I get a response with the corresponding HTML of the page")
def i_get_a_response_with_html(context):
    html = parse_html(context["response"].content)
    assert html.title = "a cake"
    assert ...

[1Mark]

This is just a dirty workaround. Users can then just put anything inside of context. Also the name context isn't very useful. I don't see why you're against such a change. There is a genuine use case and instead of supporting it you just want everyone to use a workaround.

:(

[youtux]

Indeed this is a use case, maybe the result of a when/then step can be injected as a fixture in the context, so that assertions can refer to it more naturally.

@olegpidsadnyi what do you think about allowing when/then steps to have a target_fixture param to store the result of the step? Maybe one more motivation for it is that you could have "then" statements that can assert on an object that is created by the setup, or as a result of a user interaction.

For example:

Feature: Blog

    Scenario: Publishing the article
        Given there is an article

        When I go to the article page
        And I press the publish button

        Then the article should be published

    Scenario: Creating the article
        When I go to the create article page
        And I press the create button

        Then the article should not be published

and the steps could be defined like

from pytest_bdd import scenario, given, when, then

scenarios(...)

@given("there is an article", target_fixture="article")
def there_is_an_article():
    return create_test_article()

...

@then("there should be a new article")
def there_should_be_a_new_article(session, target_fixture="article"):  # <-- Important bit here
    article session.query(Article).order_by(Article.id.desc()).first()
    assert article is not None
    return article

@then(parsers.re(r"the article should (?P<negation>not )be published")
def article_is_published(article, negation):  # <-- this article comes either form the Given step or the Then step
    expected = not negation
    assert article.is_published is expected

[1Mark]

@olegpidsadnyi please tell me you agree with me

[olegpidsadnyi]

@1Mark @youtux I've never needed that before since we were using splinter with the common browser fixture. Or the database. That was the common context. I can't think of a harm if we make the target_fixture similar to the way the parsed step params are working. Let's go for it