TestLens

See what your API tests miss

Instantly measure your API test coverage and identify missing endpoints in seconds.

🚀 Analyze Coverage

No login required • 100% free • Runs in your browser

Why TestLens?

  • Find untested endpoints instantly
  • Improve API test confidence
  • No setup, no login
1

Swagger

File or URL

2

Postman

Collection JSON

3

Compare

Run report

Upload your files to analyze API coverage

All processing runs in your browser — nothing is uploaded to a server.

▸ GitHub Pages & OpenAPI URLs

Pasting an OpenAPI URL may fail until you upload the JSON file (most reliable) or hard-refresh after updates. Ad blockers can block CORS relays.

▸ CORS & fetch

Many APIs block direct fetch from GitHub Pages. This app retries via public relays; if that fails, save the OpenAPI JSON and upload it. The durable fix is Access-Control-Allow-Origin on the spec URL.

Run analysis

Add your OpenAPI spec (URL or file) and Postman collection, then compare.

OpenAPI / Swagger

Must end with .json or use ?format=json. If CORS blocks the request, upload the file below.

Skip the URL if you already have openapi.json on disk.

Drag & drop or click — OpenAPI / Swagger JSON

Required. Export your collection as JSON from Postman.

Drag & drop or click — collection JSON (required)
▸ Important: parameter matching & optional mappings

If Swagger and Postman use different path parameter names for the same endpoint, coverage can look wrong unless you understand how matching works — or add explicit mappings below.

Open this section for the full rules, examples, and optional Swagger ↔ Postman name maps. You can still run Compare without opening it when your path templates already align.

How Parameter Matching Works

?

This tool automatically normalizes path parameters and also allows optional manual mapping below for advanced use cases.

Path parameters in Swagger and Postman may have different names, but represent dynamic values.

This tool normalizes ALL path parameters by replacing any {parameter_name} with a standard placeholder {param}.

Example: multiple path parameters

Swagger

GET /v1/sites/{site_id}/domains/{domain_id}/records/{record_id}

Postman

GET /v1/sites/{id}/domains/{dom_id}/records/{recId}

↓ Normalization ↓

Both become

/v1/sites/{param}/domains/{param}/records/{param}

Treated as MATCH

Matching is based on:

  • HTTP method (GET, POST, etc.)
  • Path structure
  • Number and position of parameters

Parameter names are ignored during comparison.

Edge case

If the number or position of parameters differs, endpoints will NOT match.

/v1/sites/{param}/domains

≠

/v1/sites/{param}/domains/{param}

NOT a match — different parameter count / structure

Path Parameter Mapping (Optional)

Optionally map Swagger path parameters to Postman variables when names differ. Example: {hosting_id} → {hosting_account_id}

You can add multiple mappings for different endpoints.

If no mapping is provided, parameters are automatically normalized (e.g., {id} → {param}).