Thirteen checkout scenarios, and each one starts by filling in the six-field registration form, confirming an email, and setting a password. That is about forty seconds before the scenario reaches the thing it is testing, and when registration breaks, thirteen checkout tests go red and the actual registration test is lost in the noise.
I know this is wrong. What I do not know is what the right shape looks like when the setup genuinely has to happen.
Accepted answer
The registration form is one scenario's subject and thirteen scenarios' setup, and those are different jobs. Do the setup through the API and keep the browser for the part under test:
@hybrid @regression
Scenario: A registered member can check out
Given I generate a "user" from the factory as "newUser"
When I send a POST request to "/members" with body:
"""
{ "email": "{{newUser.email}}", "name": "{{newUser.firstName}}" }
"""
Then the response status should be 201
When I save the response JSON path "id" as "memberId"
Given I register cleanup DELETE "/members/{{memberId}}"
When I navigate to the "checkout" pageThree things you get: forty seconds back, a failure that means one thing, and a cleanup registered next to the create rather than in a hook that never runs.
When registration then breaks, exactly one scenario goes red, and it is the one named after registration.
Worth knowing how the factory behaves before you build on it: faker is seeded from the scenario fingerprint, so a retry of the same scenario regenerates the same values. That is what you want for a retry — the second attempt hits the same data as the first, so a flake is a flake and not a different test.
The corollary is that two different scenarios have different fingerprints and get different values, so it is not a source of collisions. But it does mean the "unique" email in your scenario is stable across runs of that scenario, which matters if the app rejects a duplicate. Add the run id or use the cleanup, do not assume the value is fresh every time.
And where the app has no create API at all — ours does not, registration is a UI-only flow behind a captcha — the answer is not to script the UI faster, it is to stop creating accounts per scenario. Pre-provision a handful, put them in the pool, and let the pool hand them out. The scenarios then test checkout with an account, which is what they were about.
Have the same question?
Ask it with the command you ran and the output you got, and it will be answered here.
Ask a question