# Test Cases: Open, Edit, and Save

> Edit a test's request, assertions, and expected response; run and delete in bulk; and use the coverage verdict to find the gaps your suite still has.

Source: https://totalshiftleft.ai/help-center/product-documentation/test-case

## 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](/help-center/product-documentation/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](/help-center/product-documentation/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](/help-center/product-documentation/project-settings) and [Test config](/help-center/product-documentation/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](/help-center/product-documentation/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](/help-center/product-documentation/test-execution).
- **Coverage still shows gaps after generating tests** — generation is bounded by the test types and techniques enabled in [Test generation settings](/help-center/product-documentation/test-generation-settings). If security tests are disabled, security gaps stay.

## Related articles

- [AI-generated tests](/help-center/product-documentation/ai-generated-tests)
- [Endpoint management](/help-center/product-documentation/endpoint-management)
- [Test run](/help-center/product-documentation/test-run)
- [Test config](/help-center/product-documentation/test-config)
- [Test generation settings](/help-center/product-documentation/test-generation-settings)