I built a free tool that generates Playwright API tests from OpenAPI specs — thoughts?

Discussions
,
1

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?

2

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?

4

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.