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.
Partner contracts static
Checks that a third party still answers what the contract we copied promises, with requests generated from that contract.
The bank is not ours. We copied its contract, Microcks replays it to our tests and the greeting trusts it: if the bank changes what it answers, every test stays green on the replay while the real greeting breaks. Schemathesis reads the copy, generates requests from it and checks each answer of the real partner against it. Red here means our copy is no longer true.
Goal usernames of every shape the contract allows (empty, accented, very long) never crash the bank, and every answer is one the contract describes, the "no account" 404 included.
- Given the contract of the Bank Partner
- When schemathesis sends 50 requests generated from it
- Then no answer is a server error
- And every status code is documented by the contract
- And every body matches the schema of its status code
Goal the answers the greeting really uses, a known customer's balance, keep the fields and types of the contract, the amount in integer cents.
- Given the contract of the Bank Partner
- When schemathesis asks the balance of "<username>"
- Then the partner answers 200
- And every body matches the schema of its status code
Examples, one run per row
| username |
|---|
| ada |
| grace |
Goal the bank only answers its clients: without the long-lived key it issued us (kept in Vault), the answer is a 401, documented by the contract.
- Given the contract of the Bank Partner
- When schemathesis asks the balance of "ada" without the key
- Then the partner answers 401
- And every body matches the schema of its status code