Pipelines

Pipelines chain multiple test plans together and run them sequentially on the same browser instance. Cookies, localStorage, and session data persist from one step to the next.

This means you can log in once and run multiple tests against the authenticated session, instead of repeating the login flow in every test.

How It Works

A pipeline has one or more pre-steps that run before the main test plan. Each step is its own AI agent conversation with its own prompt, but they all share the same browser.

Pre-step 1 (Login) → Pre-step 2 (Setup data) → Main test plan

The agent in each step doesn't remember previous steps, but it doesn't need to. The browser state carries everything forward. If step 1 logs in, step 2 is already logged in.

Key Properties

• Same browser - One browser instance stays open for the entire pipeline
• State persists - Session data, cookies, DOM state all carry forward
• Independent agents - Each step gets a fresh agent conversation
• Fail-fast - Optionally abort remaining steps when a pre-step fails

Creating a Reusable Pre-Step

Pre-steps are regular test plans that accept input parameters. Use the {{ input.xxx }} syntax to declare parameters:

Go to https://myapp.com/login and sign in with email {{ input.email }} and password {{ input.password }}

Input Parameter Syntax

Example Pre-Step: Login

Go to https://myapp.com/login
Enter {{ input.email | credentials.loginEmail }} in the email field
Enter {{ input.password | credentials.loginPassword }} in the password field
Click the Sign In button
Verify the dashboard loads successfully

This step can now be reused by any test plan that needs authentication.

Attaching Pre-Steps to a Test Plan

1. Create or edit a test plan
2. Click Add pre-step
3. Select the pre-step test plan from the dropdown
4. Fill in the input parameter values
5. For credential values, click the key icon next to any input field to select from stored credentials

When you run the main test plan, all pre-steps execute first in order, then the main test runs on the same browser.

Credentials in Pipelines

When you reference stored credentials as input values, the AI agent never sees the actual values. Your passwords and secrets are only used at the moment the browser types them into a form field.

• Prompts show placeholders, not real values
• Agent conversations never contain credentials
• Test reports redact credential values
• Screenshots may show masked form fields

See Credentials for more on secure value storage.

Pipeline Reports

Each step in the pipeline generates its own report with screenshots, steps taken, and pass/fail status.

While a pipeline is running:

• A progress bar shows step badges at the top
• The active step shows a spinner
• Completed steps show a checkmark or X
• Click any completed step to review its screenshots

On the Runs page, pipeline jobs are grouped into a single row with a Pipeline badge.

Fail-Fast Behavior

When adding a pre-step, you can check "Fail entire test if a pre-step fails." This aborts all remaining steps if any pre-step fails.

This is useful when later steps depend on earlier ones. If login fails, there's no point running the checkout test.

Without fail-fast, remaining steps still execute. This can be useful when steps are independent and you want results from all of them.

Common Patterns

Login Then Test

The most common pipeline pattern. Create one login pre-step and attach it to every test that needs authentication.

Pre-step (Login):

Go to https://myapp.com/login
Enter {{ input.email | credentials.testEmail }} in the email field
Enter {{ input.password | credentials.testPassword }} in the password field
Click Sign In and verify the dashboard loads

Main test (Dashboard verification):

Verify the dashboard shows:
1. At least one project in the sidebar
2. The user's name in the top-right corner
3. The "Create Project" button is visible and enabled

Multi-Step CRUD

Test create, read, update, and delete as separate steps sharing state:

1. Step 1 - Create a new item
2. Step 2 - Verify it appears in the list
3. Step 3 - Edit the item
4. Step 4 - Delete it and verify it's gone

Each step is independently debuggable. If delete fails, you don't re-run the entire flow.

Multi-Role Testing

Test different user perspectives in sequence:

1. Step 1 - Log in as admin, create an invite link
2. Step 2 - Log in as new user, accept the invite
3. Step 3 - Verify both accounts see the correct state

Pipelines vs Cookie Injection

Both solve the authentication problem, but in different ways.

Use cookie injection when:

• You just need to skip the login page
• You can extract session cookies from your app
• Speed matters most (CI runs)
• Your auth uses external providers (Google, GitHub SSO)

Use pipelines when:

• You're testing the login flow itself
• Your app uses HTTP-only cookies that are hard to extract
• You need multi-step setup beyond just auth
• You want reusable building blocks that team members can compose

They're not mutually exclusive. Use cookie injection for most tests and pipelines where you need actual browser interaction during setup.

Running Pipelines via API

Pipelines run automatically when you trigger a test plan that has pre-steps configured. No special API parameters needed:

curl -X POST https://test-lab.ai/api/v1/run \
  -H "Authorization: Bearer tl_xxxxx" \
  -H "Content-Type: application/json" \
  -d '{"testPlanId": 123}'

If test plan 123 has pre-steps, they execute first. The API response includes step-level status.

Tips

1. Keep pre-steps focused - One action per step (login, seed data, navigate to a section)
2. Use credentials - Never hardcode passwords in pre-step prompts
3. Enable fail-fast - Unless steps are truly independent
4. Reuse widely - A good login pre-step can be shared across dozens of test plans
5. Test pre-steps independently - Run them as standalone tests first to verify they work

Next Steps