Hey MoT community,
I’ve been working on a small tool for teams that use TypeScript + Playwright for testing and have an OpenAPI/Swagger spec.
Instead of manually writing boilerplate API tests (happy path, auth check, validation), you paste or upload your spec, pick an endpoint, and get a ready-to-run .spec.ts file.
It generates:
- Happy path test
- 401 auth check (only if your spec declares a security scheme)
- 422 input validation (from your schema’s required fields and types)
- 404 contract check (if path params exist)
Free, no login, no install: https://swagger-to-playwright.vercel.app
I’m curious what a QA-focused perspective brings here — what would make this genuinely useful vs. a toy? What’s missing from a real workflow?
A few things I would find valuable:
- Support for reusable authentication rather than embedding auth in every generated test.
- Generate tests that fit existing Playwright project structures (fixtures, page objects/helpers, config, etc.).
- Idempotent test data handling, since many APIs can’t safely be called repeatedly with the same payload.
- Easy regeneration when the OpenAPI spec changes without overwriting custom assertions.
- Tags or grouping for smoke, regression, or contract tests.
- Negative scenarios beyond 401/404/422, especially boundary values and business-rule validations that OpenAPI alone can’t infer.
- Mocking support for dependent services where appropriate.
- CI-friendly output and reporting recommendations.
One question that I would ask is how do you see this fitting into long-term maintenance? Is the goal to generate tests once as a starting point, or to regenerate them whenever the API spec evolves?
Thanks for the detailed breakdown, Ujjwal — this is exactly the kind of feedback that helps clarify what the tool is and isn’t trying to be.
To answer your question directly: the current goal is the first option — generate once as a starting point. The intent is to eliminate the boilerplate: the repetitive scaffolding of happy path, auth check, input validation, and contract tests that you’d write the same way for every endpoint. The thinking stays with the engineer — which assertions actually matter, what edge cases are specific to your business logic, how tests fit your team’s structure.
A few of your points (reusable auth, fixture-aware output, test tags) are things I want to improve because they reduce the gap between generated output and something you can drop straight into a real project. Others, like boundary value testing and business-rule validations, are intentionally out of scope for now — the spec doesn’t encode that knowledge, and guessing would produce noise rather than signal.
The regeneration question is the interesting one. The current answer is: generate once, then maintain manually. Whether it makes sense to evolve toward partial regeneration — only touching auto-generated sections, leaving custom assertions intact — is something I’m still thinking through. Your point about not overwriting custom assertions is exactly the right constraint for that to work.
3-week update: The tool is now open source — GitHub - j0ny3ngliSh/swagger-to-playwright: Generate ready-to-run Playwright API tests from an OpenAPI/Swagger spec · GitHub
What’s been added since this post:
- Download the full test suite for all endpoints in one zip (68 endpoints downloaded by real users so far)
- Input validation tests per field (missing required, wrong type, invalid enum)
- Auth test only generated when the spec actually declares security
221 visitors, 46 returned, 7 full suite downloads. Still free, no login.
Thanks for the feedback in this thread — it directly shaped what got built. If you’ve found it useful, a 
on GitHub helps others find it.
the open-source move helps, but this gets useful when the generated suite makes its confidence boundary obvious. i’d label which checks came directly from the OpenAPI contract and which assumptions still need a human: auth roles, idempotent data, side effects, and business rules.
i’d also generate a clean-session run plus a negative control for each mutating endpoint. that catches the dangerous case where a spec-shaped test passes against leftover state.
have the seven full-suite users edited the generated tests, or are they running them as-is? that answer probably tells you whether the tool is scaffolding or becoming part of maintenance.
@dwaynesamuels all three are sharp observations.
The confidence boundary labeling makes sense — right now the auth test is contract-driven (only generates if the spec declares a security scheme), but the validation test is more assumption-prone. Making that distinction visible in the output would help users know where to trust and where to verify.
The clean-session + negative control point is a real gap. Spec-shaped tests passing against leftover state is exactly the kind of false confidence that makes a suite misleading.
On the seven users — honest answer is I don’t have visibility into that. No telemetry on what happens after the ZIP is downloaded. My guess is scaffolding: generate, understand the structure, delete what doesn’t fit. But that’s a guess. If anyone reading this has used it, I’d genuinely like to know.
that telemetry gap is probably the next thing to fix before adding more generators. keep it opt-in and lightweight: give each ZIP a run ID, link to a one-click feedback form, then ask whether the suite ran unchanged, was edited, or was discarded.
downloads show interest. the first clean-session run, first failing negative control, and first assumption a user rewrites tell you whether this is scaffolding or maintained test code.