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
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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:I think this is fine, but the documentation should probably have a big warning so that users are fully aware of how it works.
The text was updated successfully, but these errors were encountered: