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.
Ten customers greet themselves for half a minute, each call going through the storefront, the API, the database, the partner bank and Redis. k6 plays the load, the scenario reads its summary: the same numbers a load test job files in Test results.
Goal the greeting stays fast and reliable with several customers at once, not only for one tester clicking: under 1% of failed calls, 95% of the greetings in less than 500 ms.
- When k6 plays "customer-welcome-baseline.js" against the storefront
- Then less than 1 percent of the calls fail
- And 95 percent of the greetings answer within 500 ms