API test case generator from OpenAPI

What the generator produces, and why each case is there

An OpenAPI document already describes most of what a test suite needs to check: which parameters are required, what type each field is, which values are allowed, which errors the API promises and which endpoints need credentials. This tool reads that description and turns each rule into a test case. It works operation by operation, so the pack keeps the shape of your API. The output is a plain table, not a framework, so you can drop it into a test-management tool, a spreadsheet or a pull-request checklist.

Positive case and response-schema check

Every operation gets one positive case. It sends only the required parameters and body fields, filled from your example and default values, or from sensible placeholders for the declared type and format. The expected status is the first 2xx response the spec documents. When that response has a schema, a second case asserts that the body matches it, naming the required fields. A spec-correct status with a wrong body is one of the most common regressions, and it is the one that breaks API consumers first.

Required fields and invalid types

For each required query, header or cookie parameter, and for each required top-level body field, the pack has a case that leaves that one item out and keeps the rest valid. Changing one thing at a time means a failure points straight at the rule that broke. Invalid-type cases send a string where the spec says integer, a scalar where it says array, and a number where a JSON body expects a string. String query parameters are skipped, because on the wire every query value is a string. Read-only properties are left out of request cases.

Boundary values

Boundary value analysis is where hand-written suites are usually thinnest. For every numeric minimum and maximum (exclusive bounds included), the pack has an accepted case at the limit and a rejected case just past it. String minLength and maxLength, and array minItems and maxItems, get the same treatment. For enum fields there is a case that cycles through the allowed values and one that sends a value outside the list. format (email, uuid, date, date-time, uri) and pattern get a violation case of their own.

Authentication and not-found

When an operation requires security, through its own security block or the global one, the pack adds a case with no credentials and a case with malformed or expired credentials. Both expect 401. OAuth 2.0 requirements with scopes also get a token-without-scope case that expects 403. Operations that opt out with security: [] get none. Every path parameter gets a not-found case using an id that should not exist, so you can confirm the API returns 404 and not a 500 or someone else's record.

Pagination

If an operation takes limit, offset, page, cursor or a common variant, the pack checks that the page size is respected, that a page past the end comes back empty and not as an error, that a tampered cursor is rejected, and that walking every page returns each item exactly once. Duplicate and missing items across pages are a classic bug that per-request tests never see.

Honest expected statuses

Expected statuses come from your spec. If an operation documents a 422 and no 400, validation cases expect 422. If it documents neither, the case says "400 or 422" with a note, and does not guess. If the pack shows many notes, the spec is missing error responses. The OpenAPI test-readiness scorer shows exactly where.

What it does not do

It does not send requests, so it cannot tell you whether your API passes. It does not follow external $ref files, and it covers top-level body fields rather than every nested property. It also does not cover business rules that the spec cannot express, such as "an order cannot be cancelled after it ships". For how to write those by hand, see how to write API test cases. For a coverage model to measure the whole suite against, see the OpenAPI test coverage guide.