Gherkin scenarios
The acceptance scenarios of features/, one section per product. Run runs a whole feature or one scenario against the stack mise run up started; the run also lands in Test results.
The Driven by filter keeps the features of one tool. Run feature runs every scenario of a feature, Run one scenario. The Gherkin runner starts pytest-bdd against the running stack, the verdict shows above with the pytest output, and the run is filed in Test results like a CI job. The stack down, the scenarios skip and say how to start it.
live products write for real when their scenarios run (Redis visits, orders, accounts, emails); static ones only read.
Each feature says what drives its scenarios, a badge beside its name from its @tool- tag: pytest (pytest-bdd steps calling the stack over HTTP or the bucket), playwright (steps clicking the storefront page in a real Chromium, written from a recorded journey), schemathesis (requests generated from a contract), k6 (a load played by k6, its summary read by the steps). Every one still runs through pytest-bdd, so the console runs and files them alike.
Customer welcome live
Greets a returning customer by first name, counts the visits and shows the bank balance.
🛍️ Try it by hand in Live experimentation: the same product the scenarios below prove, opened alone on the storefront.
The journey a customer clicks, recorded and written in the template of a recorded scenario: who plays, from which data, what is seen. Playwright drives a real Chromium on the storefront of the running stack.
Goal what the customer really sees, not only what the API answers: the page greets them by first name and shows the balance the bank holds.
- Given "ada", a customer of the company who can see their bank balance
- And the partner bank holds an account for "ada"
- When "ada" greets themselves on the storefront page
- Then the page greets "Ada" with a balance in EUR
Checkout live
Places an order and follows it while stock is reserved, the invoice issued and the payment captured.
🛍️ Try it by hand in Live experimentation: the same product the scenarios below prove, opened alone on the storefront.
The checkout journey a customer clicks, recorded and written in the template of a recorded scenario. Playwright fills the order form of the storefront and watches the workflow steps the page draws as the worker runs them.
Goal the page follows the asynchronous workflow to the end on its own, the customer never reloads: three steps turn done, the order reads paid.
- Given "ada", a customer of the company who can order
- And the stock of "BK-0004" holds at least 1 item
- When "ada" orders 1 "BK-0004" on the storefront page
- Then the page shows every step done and the order paid
Account access live
Creates an account, signs in, resets a password, with every email landing in the QA mailbox.
🛍️ Try it by hand in Live experimentation: the same product the scenarios below prove, opened alone on the storefront.
The sign-in a customer clicks, recorded and written in the template of a recorded scenario. The account is test data like any other: the scenario creates its own, with a password, so it never depends on the account of whoever recorded it.
Goal a customer with a password reaches their account from the page, the form sending what the tenant expects and showing who is signed in.
- Given "a new customer", a customer account who can sign in with a password
- And a new account of the QA mailbox whose password is "Foundation-2026"
- When the customer signs in on the storefront page with "Foundation-2026"
- Then the page says the customer is signed in