# Test Configuration

> Define environments, variables, headers, and datasets so tests run consistently across dev/stage/prod without hardcoding secrets or setup.

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

## Overview

Test configuration keeps tests portable across environments: instead of hardcoding base URLs, headers, and inputs into every test, you define them once on the project and inject them at run time. Environments, project-level headers, and run data all live in the project editor; a separate **Test Configurations** modal captures reusable per-endpoint request shapes. Use these together so the same test runs cleanly against Dev, Staging, and Production.

## Before you begin

- You need a project you can edit.
- Decide which environments you'll target (for example Development, Staging, QA, Production) and where run data comes from.
- Nav path: open the **project editor**. The tabs used here are **Environment Settings** and **Data for Running Tests**. The **Test Configurations** modal is opened from the test-configuration control in the app toolbar.

## Step 1 — Set base URLs per environment

1. In the project editor, click the **Environment Settings** tab.
2. Under **Base URLs by Environment**, each configured environment has a row with a radio button (the default environment), the environment name, and a base-URL field (placeholder like `e.g. https://api-development.example.com`). Enter the base URL for each environment you use.
3. Select the radio button on the environment you want as the **default**—the one tests use unless overridden at run time. Archived environments can't be set as default.
4. To add another environment, use the **Add Environment** row: enter a name and base URL, then save. Existing environments can be archived (hidden from dropdowns, history preserved) or deleted with the row buttons; you can't archive or delete the current default.

## Step 2 — Add project-level headers

1. Still on **Environment Settings**, scroll to **Project-Level Headers**.
2. Click **Add Header** to add a row, then fill the header **name** and **value** (for example an auth, tenant, or correlation-ID header). Remove a row with its trash button.
3. These headers are applied to tests in the project so you don't repeat them per test. Store secrets in your secret manager rather than pasting raw credentials.

## Step 3 — Save the configuration

Click **Save Settings** at the bottom of the tab. Blank header rows (missing name or value) are dropped on save. If a save fails, a dismissible red error banner appears at the top of the tab.

## Step 4 — Attach data for data-driven runs

Open the **Data for Running Tests** tab to make tests run once per row of data instead of a single hardcoded input. Studio has two complementary systems:

- **Datasets and the Data-Driven testing panel** — internal tables, saved datasets, or generated data, bound with `{{row.COLUMN}}` tokens. See [Data-driven testing](/help-center/product-documentation/data-driven-testing).
- **Data Sources** — reusable connections to CSV / Excel / Database / JSON / API, bound with `[[variable]]` tokens. See [Data sources](/help-center/product-documentation/data-sources).

## Step 5 — Create a reusable endpoint configuration (Test Configurations)

The **Test Configurations** modal stores reusable per-endpoint request shapes that generation and tests can build on.

1. Open the **Test Configurations** modal. It lists existing configurations as cards (method chip, name, path, parameter count, and any auth / rate-limit chips).
2. Click **Add Configuration** to create one, or the **edit** (pencil) icon on a card to change one. The form opens with these sections:

| Field | What it does |
|-------|--------------|
| **Name** | Label for the configuration (required). |
| **Method** | GET, POST, PUT, PATCH, or DELETE. |
| **Path** | The endpoint path (required). |
| **Description** | Optional free-text notes. |
| **Parameters** | Add rows with **Name**, **Type** (String / Number / Boolean / Array / Object), and **Description** via **Add Parameter**; remove with the trash icon. |
| **Request Body (JSON)** | A JSON object representing the request-body schema. |
| **Authentication** | Tick **Requires Authentication** to reveal **Type** (none, basic, bearer, apiKey, oauth2) and an **Auth Config (JSON)** object. |
| **Rate Limiting** | Tick **Enable Rate Limiting** to set **Requests** and **Period (seconds)**. |
| **Custom Test Suggestions (optional)** | Method-specific suggestion text you can override or extend; leave blank to use the defaults shown above the field. |

3. Click **Save**. Invalid JSON in **Request Body** or **Auth Config** is rejected with an alert (*"Invalid JSON in Request Body"* / *"Invalid JSON in Auth Config"*). A confirmation snackbar reports success; delete a configuration with the trash icon on its card.

## Troubleshooting

- **"Invalid JSON in Request Body" / "Invalid JSON in Auth Config"** — fix the JSON syntax in the Test Configurations form before saving.
- **Can't archive or delete an environment** — it's the current default; set another environment as default first.
- **Headers didn't save** — rows missing a name or value are dropped on save; fill both fields.
- **Test hit the wrong host** — confirm the base URL for the selected environment and that the intended environment is set as default on **Environment Settings**.

## Best practices

- Keep one base URL per environment and name environments clearly (Dev, Staging, Prod).
- Rotate tokens and secrets; avoid committing sensitive values or pasting them into config fields.
- Use unique IDs per run to prevent collisions, and update configuration when endpoints, environments, or auth mechanisms change.

## Related articles

- [Data-driven testing](/help-center/product-documentation/data-driven-testing)
- [Data sources](/help-center/product-documentation/data-sources)
- [Configuration fundamentals](/help-center/configuration/environment-variables)
- [Test case](/help-center/product-documentation/test-case)