Overview

A test case is one request against one endpoint, plus the assertions that decide whether the response was correct. Tests belong to an endpoint — select an endpoint in the sidebar to see its tests.

Until you do, the panel reads No Endpoint Selected — "Please select an endpoint to view its tests."

The tests table

Each endpoint's tests are listed with:

Column	What it shows
Test Name	The test's name.
Description	What the test covers.
Status	The result of its last run.
Last Run	When it last ran.
Actions	Edit, run, delete.

You can select multiple tests and act on them together. Bulk Run Summary reports the outcome of a multi-test run, and bulk deletion asks for confirmation first — Confirm Bulk Deletion.

Editing a test

Opening a test for editing gives you these sections:

Section	What you set
Endpoint details	The operation under test.
Test details	Name and description. Worth caring about — these are what you read in a report at 3am.
Request config	Path and query parameters, headers, and request body.
Request validation	Checks applied to the request itself.
Expected response	The status and body you expect back.
Assertions	The individual checks that decide pass or fail.
Data source and auth	Which test data and authentication profile the test uses.
Data extraction	Pull values out of the response for later use — the basis of chaining steps together.
Test script	Scripted logic, when the declarative options aren't enough.

Changes aren't saved until you save them. If you navigate away with unsaved work, you'll be warned rather than silently losing it.

Test types

Tests fall into five types: status, format, data, performance, and security. These are also the types AI generation can produce — see Test generation settings.

Coverage verdict and gaps

The tests table doesn't just list what you have — it analyses what you're missing. The coverage verdict reports Gaps with a Severity of Critical, High, or Medium across these categories:

Category	What it checks for
Functional (status codes)	The endpoint's expected success and failure statuses.
Auth depth (401/403)	Unauthenticated and unauthorized access.
Routing & methods (405/404)	Wrong method, missing resource.
HTTP semantics (Content-Type)	Correct content negotiation.
Schema / contract	The response matching the contract.
Data integrity	The response data being correct, not just well-shaped.
Error body validation	Error responses being structured, not just having the right status.
Performance / SLA	Response time within expectations.

When there's nothing to report, it says No coverage gaps identified.

This is the most useful thing on the page and the most often ignored. A suite of twenty tests that all check 200 OK will look healthy on pass rate and be flagged here as missing auth depth and error body validation — which is exactly the gap that lets a real bug through. Read the gaps before adding more happy-path tests.

Test design techniques

Generated tests can apply formal design techniques — Boundary values, Equivalence partitioning, and Decision table. Configure which are used in Test generation settings.

These matter most on endpoints with constrained inputs: a field accepting 1–100 has interesting behaviour at 0, 1, 100, and 101, and boundary generation produces those cases without you enumerating them.

Best practices

Test failure, not just success. The coverage verdict exists because success-only suites are the norm and they don't catch much.
Name tests so a report is readable. Rejects order with negative quantity beats Test 4.
Never hardcode credentials or environment-specific values. Use the authentication profile and environment from Project settings and Test config, so the same test runs in dev and staging.
Use data extraction rather than hardcoded ids. A test that depends on order 123 existing will fail on a fresh environment.
Let the gaps drive what you write next. They're derived from the endpoint's contract, so they're a better to-do list than intuition.

Troubleshooting

"No Endpoint Selected" — select an endpoint in the sidebar; tests hang off endpoints.
A test passes locally and fails in another environment — usually a hardcoded value. Check the request config for environment-specific hosts, ids, or tokens.
Every test on an endpoint fails with 401/403 — the authentication profile, not the tests. See Project settings.
A test fails with Error rather than Failed — the request never completed. That's connectivity or configuration, not an assertion problem. See Test execution.
Coverage still shows gaps after generating tests — generation is bounded by the test types and techniques enabled in Test generation settings. If security tests are disabled, security gaps stay.

Test Cases: Open, Edit, and Save