Gherkin to Playwright
Test scenarios in plain language (for POs and QA) become automated Playwright tests (for developers).
What is this?
An acceptance test describes, in plain language, how the system should behave for the people who use it. The most common format is called Gherkin: a Feature, its Scenarios and the steps of each one, with Given (the situation), When (the action) and Then (the expected result). This tool turns that text into a Playwright test, which opens a real browser and repeats the script on its own after every change to the system.
For whoever describes (PO, QA)
Write scenarios the way you would test by hand, using the phrases in the cheat sheet so that as much as possible becomes code without help. The acceptance script stops being repeated by hand at every release and becomes documentation that runs.
For whoever automates (developer)
Get a test that compiles: the structure always comes out exact and known phrases come already implemented. Unknown ones become pending steps that fail with a clear message until you implement what they do.
Unit, integration or acceptance: what is the difference?
| Type | Who writes it | What it checks |
|---|---|---|
| Compilation | Nobody: it is automatic | Whether the code is valid (types, names). It does not say whether the math is right. |
| Unit | Developer | One function in isolation, no browser. E.g. the check digit of a tax ID. |
| Integration | Developer | Several real parts together. E.g. the API writing to the database. |
| Acceptance (end-to-end) | PO, QA or developer | The whole system, the way a person uses it. This is what this tool generates. |
The types coexist: each one catches errors the others cannot see. Many small tests at the base, few large ones at the top.
Generated code
By using the tools, you agree to the terms of use.