Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update documentation with minor detail about the fixtures decorator #91

Closed
dolan-a opened this issue Mar 21, 2019 · 4 comments · Fixed by #98
Closed

Update documentation with minor detail about the fixtures decorator #91

dolan-a opened this issue Mar 21, 2019 · 4 comments · Fixed by #98
Labels

Comments

@dolan-a
Copy link
Contributor

dolan-a commented Mar 21, 2019

While writing up notes on settings overriding, I was thinking about how the fixtures decorator works, and I realized that the order of steps doesn't matter with regards to when the fixture is loaded; it'll always be loaded before all steps.

For example, in the following, the 4th step (Then user with pk="1" has a name of "john") would fail because the fixture loading happens before step 1, even though step 3 is where the decorator is, and then step 1 sets the user's name to "bob", thus step 4 fails:

# Step function:
@fixtures('users.json')
@given('Given I load a fixture of users (including pk=1 and name=john)')
def step_impl(context):
    pass

# Gherkin file:
Scenario: User test name
    Given I create a user with pk="1" and name="bob"
    Then user with pk="1" has a name of "bob"
    Given I load a fixture of users (including pk=1 and name=john)
    Then user with pk="1" has a name of "john"

I think this is fine, but the documentation should probably have a big warning so that users are fully aware of how it works.

@bittner
Copy link
Member

bittner commented Mar 21, 2019

If the implementation is misleading we should probably fix that.

The problem here seems to be that we're actually attempting to do things that are out of our control: We can't (currently) influence what behave is doing from the monkey patching piece of code. -- Or can we?

Maybe that means that we should do fixture declarations in the feature files rather than Python code. -- This starts to sound ugly. It really should be all plain Python, not its own type of test language.

@dolan-a
Copy link
Contributor Author

dolan-a commented Mar 21, 2019

The idea of feature fixture declarations in the feature files is appealing, but I don't like that the feature files would no longer be valid Gherkin syntax, unless of course we do some sort of hack on tags (e.g. @fixture__myfixture.json or something.

I vote to keep the code as is, and just make it clear in the documentation that when using the the fixtures decorator, the fixture will apply to all sibling steps in a scenario.

@bittner
Copy link
Member

bittner commented Mar 22, 2019

I agree. A PR is welcome. 👍

@bittner
Copy link
Member

bittner commented Apr 5, 2019

Would you be ready to tackle this issue, too? 😬

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants