Example
Playwright, Postman and CI starter kit
A versioned, executable local shop example with isolated sessions, browser/API checks, repeat-request and refused-access scenarios, a CI gate and Allure results.
Download editable MarkdownDownload starter kit v1.0.0 (ZIP)How to use this
Useful for: Engineers evaluating a small maintainable test framework before adapting it to their own application.
Download the archive and follow its README in an isolated workspace. The fixture binds to loopback and uses synthetic products; do not expose it as a production shop.
Run the included checks before adapting the example. Each test owns its browser session and data, which makes the refusal and repeat-request cases independent of another worker.
Inspect the trace and Allure results to understand a failed assertion. Reports explain a run of this fixture; they do not establish coverage for your product.
Replace the sample policy and assertions with your agreed requirements. Add explicit ownership for fixture creation, cleanup and pipeline failures before using the framework as a release gate.
Scope and limitations: Educational local fixture, version 1.0.0. It has no payment processing or production authentication. Sample results and traces concern this fixture only.
Document preview
# QA starter kit — version 1.0.0 ## Released 11 October 2026 The downloadable archive contains a local Node.js fixture, pinned test dependencies, a lockfile, Playwright tests, a Postman collection, CI configuration and example report artifacts. Read the archive's README for the exact commands and supported runtime. ## Architecture Browser or API test -> isolated session -> local fixture -> recorded assertion -> trace / Allure result -> human investigation. The server owns synthetic products and order records. A browser context receives a separate session, so one test cannot quietly read or mutate another test's order. The expectation is written independently of the response: the known product costs 2000 minor units and the required total for two units is 4000. ## Checks - A buyer adds a product and receives the expected order summary. - An API client creates an order with the specified quantity and amount. - A repeat request with the same idempotency key has one business effect. - Reusing that key for a different payload is refused. - A different session cannot read the first session's private order. - Invalid quantity is rejected without creating an order. ## Fixture ownership Each test gets its own context and synthetic state. The test server starts with a fresh in-memory store. Avoid importing production accounts or making assertions against mutable customer data. The example does not demonstrate a database cleanup strategy; adapt that boundary deliberately for a real application. ## CI gate The included workflow runs the scoped checks and preserves diagnostic artifacts on failure. It does not treat retries as a repair or claim that a green run covers unrelated functionality. Review which checks should block a merge and who investigates a red result. ## Reports and updates The kit records dependency versions in its lockfile and release date in its README. Re-run the tests when updating the dependencies or fixture. Allure data and traces are inspectable execution examples; regenerate them after modifying the scenario instead of forwarding the bundled run as evidence for changed code.
Read alongside this worksheet
- Playwright vs Cypress: one architectural difference, and its consequencesThe two runners differ structurally in one way, and nearly every practical distinction falls out of it. What that means for redirects, parallelism, debugging, and who ends up maintaining the suite.
- Building a test automation framework from scratch: the first 90 daysWhat actually gets built, in what order, and why the teams that start by recording scripts end up rewriting everything.
- CI test gating: deciding what a red build is allowed to stopWiring a suite into a pipeline takes a day. Deciding what it may block is the real project, and it is a social agreement with a configuration file attached.
- When to automate a test, and when the answer is noNot a philosophy of automation but a decision taken one case at a time. Five signals, four possible verdicts, and why "keep it manual" is not the losing option.