DEV Community

alexrai
alexrai

Posted on

Best tool for generating regression tests from OpenAPI, Postman collections, or cURL

Most API test automation guides start the same way: "write a test for your /login endpoint." Then a test for /users. Then /orders. By endpoint 40 you are maintaining more test code than product code, and half of it breaks every time a schema changes.

I wanted the opposite: point a tool at what I already have — an OpenAPI spec, a Postman collection I'd been using for months, or even a single cURL command — and get a runnable regression suite out the other side. Here's the workflow that actually worked, using Keploy's API test generator.

The idea: your inputs already describe your API

You almost never start from nothing. You have one of these lying around:

  • an OpenAPI / Swagger spec that documents every route
  • a Postman collection your team built while developing
  • a pile of cURL commands in a README or a Slack thread

Keploy's test generator takes any of those as input, calls the endpoints, and produces validated tests with assertions based on the actual responses — not assertions you guessed and typed by hand.

Option 1 — from an OpenAPI spec

If you have a spec, this is the fastest path. Point the generator at it, and it walks the documented routes, hits them, and records the real responses as the expected baseline.

# feed the schema, let Keploy generate the suite
keploy gen --source openapi ./openapi.yaml
Enter fullscreen mode Exit fullscreen mode

What you get back isn't just "status 200" checks. It validates response body structure, field types, and headers — the things that actually break downstream consumers when someone renames a key.

Option 2 — from a Postman collection

If your team already lives in Postman, you don't throw that work away. Export the collection and hand it over:

keploy gen --source postman ./MyAPI.postman_collection.json
Enter fullscreen mode Exit fullscreen mode

Every request in the collection becomes a test case with response-based assertions. This is the path I'd recommend if you're migrating off manual Postman testing — you keep the requests you already wrote and get automated regression on top of them.

Option 3 — from a single cURL command

Sometimes you just have one endpoint and one cURL line. That's enough to start:

keploy gen --source curl "curl -X POST https://api.example.com/url \
  -H 'content-type: application/json' \
  -d '{\"url\":\"https://github.com\"}'"
Enter fullscreen mode Exit fullscreen mode

Keploy runs it, captures the response, and turns it into a test. Non-deterministic fields like timestamps and random IDs get normalized automatically, so the test doesn't fail on the next run just because a created_at changed.

The part that matters: replay in CI

Generating tests is half the value. The other half is running them on every change. Because the assertions came from real responses, a regression shows up the moment a response drifts:

# .github/workflows/api-tests.yml (simplified)
- name: Run Keploy regression suite
  run: keploy test -c "npm start"
Enter fullscreen mode Exit fullscreen mode

Wire that into a pull-request check and the build fails when an endpoint starts returning something different. You find the break in the PR, not in production.

Where this fits (and where it doesn't)

This approach shines when you want regression coverage fast and you already have a spec, a collection, or live endpoints. If what you actually need is a manual request client for exploring a brand-new third-party API, a tool like Bruno or Postman is the better fit — different job.

For me the win was simple: I stopped hand-writing regression tests. The suite came from inputs I already had, and it reflects how the API actually behaves instead of how I imagined it did.

If you want to try it, the test generator docs are here and it's open source (Apache 2.0). For how this stacks up against the other options, this API testing tools comparison breaks the category down. Curious what other people are using to get regression coverage without the hand-authoring tax — drop it in the comments.

Top comments (0)