# Continuous Test Stage (CTS) – Lab ID Management

## **TL;DR**

CTS (**Continuous Test Stage**) enables automatic coverage capture during a defined window without integrating with a test framework.\
Manage CTS Lab IDs for **component builds** using SeaLights APIs.

***

## **Introduction**

**What is CTS?**\
CTS stands for **Continuous Test Stage**. It captures code coverage automatically during a test stage window without requiring integration with a testing framework.

**Why use CTS?**

* Simplifies coverage collection for E2E/system tests.
* Works without test framework hooks.
* Captures all activity during the CTS window (including background jobs).

## **Sample Use Cases**

<table><thead><tr><th width="225">Use Case</th><th width="300.9998779296875">Configuration</th><th>Expected Result in Dashboard</th></tr></thead><tbody><tr><td><strong>Single Lab ID for All Tests</strong></td><td>Lab ID: <code>cts-all-tests</code><br>Test Stage: <code>FullSuite</code></td><td>Coverage aggregated for all tests under one stage</td></tr><tr><td><strong>Separate Lab IDs for Different Test Types</strong></td><td>Lab ID Pattern: <code>cts_e2e_tests</code>  and Stage: <code>E2E Tests</code><br>Lab ID Pattern: <code>cts_api_tests</code> and Stage: <code>API Tests</code></td><td>Coverage metric split by stage: one for E2E, another for API tests</td></tr></tbody></table>

## Managing Entries via API (CRUD)

### **Prerequisites**

* SeaLights tenant URL: `https://<Customer ID>.sealights.co` and a valid **API Token**.
* Application builds are reported to the SeaLights dashboard, and runtime instrumentation is active (visible in Cockpit Live Agent Monitor).
* Ability to configure Lab IDs in your test environments.

### **Component Builds (API Token)**

<table><thead><tr><th width="218.0001220703125">Action</th><th>Endpoint</th></tr></thead><tbody><tr><td><strong>Create</strong></td><td><code>POST /sl-api/v1/component-cts/config</code></td></tr><tr><td><strong>Update</strong></td><td><code>PUT /sl-api/v1/component-cts/config</code></td></tr><tr><td><strong>Delete</strong></td><td><code>DELETE /sl-api/v1/component-cts/config</code></td></tr><tr><td><strong>Get stage  by Lab ID</strong></td><td><code>GET /sl-api/v1/component-cts/config/&#x3C;Lab ID></code></td></tr><tr><td><strong>List All CTS</strong></td><td><code>GET /sl-api/v1/component-cts/config</code></td></tr></tbody></table>

#### **Payload for Create/Update:**

```
{
  "labIdPattern": "<lab ID>",
  "defaultTestStageName": "<Test stage name>"
}
```

***

## **Best Practices**

* Keep CTS windows **short and focused**.
* Pause background jobs during CTS runs.
* Use clear naming conventions (e.g., `cts-e2e`, `cts-api`).
* Assign ownership for each Lab ID.

## **Q\&A**

**Q: Do I need a test framework?**\
A: No, CTS works without test framework integration.

**Q: Can CTS exclude background jobs?**\
A: No, all activity during CTS is captured.

**Q: Can I use patterns for Lab IDs?**\
A: Yes, patterns like `cts-e2e` or `cts-api` help organize coverage by test type.