Draft API test cases from an OpenAPI operation

Choose an operation and an output format. Add authentication, fixtures and contract assertions yourself; the generated tests are not executed on this page.

Runs locally in your browser
This tool processes all data locally in your browser.
OpenAPI definitionPaste an OpenAPI 3.x or Swagger 2.0 JSON/YAML document. It is parsed locally; no server or endpoint is contacted.
Generated test cases

How to draft test cases from an OpenAPI operation

Paste an OpenAPI 3.x or Swagger 2.0 document, or open a local .json, .yaml or .yml file. The paths, parameters, request bodies and responses are read in your browser, and the operations they contain are listed for you to pick from.

Choose an operation, then choose Test plan JSON to see the cases worth covering or Vitest + fetch to get a runnable starter that builds the request. Nothing is uploaded, and no endpoint is called.

  1. Paste the definition or load a file, then press Analyze API. Every operation under paths is listed with its method, path and summary.
  2. Select the operation, pick Test plan JSON or Vitest + fetch, and press Generate tests. The result appears in the lower box.
  3. Use Copy or Download to take the result away; Clear empties the input, the operation list and the output.
  4. Before running anything, add what only you can know: authentication, real fixture values, the base URL if the document has no server, and the assertions your contract needs.

What the plan and the starter cover, and what they leave to you

What the document reading covers

Local references are followed to their definitions: parameters declared on a path, request bodies and schemas under components. Path parameters are always treated as required, as the specification demands, even when a document forgets the flag.

Swagger 2.0 documents are read as well. The base URL is composed from schemes, host and basePath, and a body parameter becomes the JSON request body. For OpenAPI 3 the first server URL is used, with server variables replaced by their default values.

What the generated code contains

The Vitest file imports describe, expect and it; declares each path parameter as a camelCase constant; builds the URL with encodeURIComponent; sets query parameters through URLSearchParams; and sends a JSON body with the matching Content-Type header. Its only assertion is that the status is 2xx.

The JSON plan lists a happy path, one missing-input case for each required parameter (path parameters and the request body included) and one case for every documented 4xx or 5xx response. Both formats read the document the same way, so the case names line up with the starter.

Where the tool stops

Everything runs in the page and the generated tests are not executed here. A green status check does not prove that the response body matches its schema, so treat the output as a draft to extend.

Very large documents are parsed in the browser too; if one becomes slow, trim it to the paths you are testing. To check the definition itself first, the OpenAPI validator in the same category reports structural and reference problems.

Recent tools: