Example threads. These questions and answers were written by the SDODS team to document real problems and how to fix them. The people named are illustrative, not real users. Questions asked on this site are marked new.
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.
Wrap commands and output in triple backticks and they will render as a code block.
Checking whether you’re signed in…
Have a different question? Ask it.