Test Data Management

Tests need data — login credentials, search queries, form values, dynamic IDs. AegisRunner manages all of it in one place per project, scoped per environment, with secrets encrypted at rest.

Where to find it

Open a project, go to Project Config → Test Environment. Four sub-tabs.

Sub-tab	What it holds
Tokens	API keys, bearer tokens, login credentials, bypass tokens. Reference with {{TOKEN_NAME}} in tests.
Cookies	Pre-auth session cookies. Injected before navigation so tests don't have to log in every run.
Headers	Custom HTTP headers applied to every request — debug flags, version pins, traffic-tagging.
Login	A Playwright-style script that runs before each test session. Templates included for common providers.

Tokens

Use tokens for any value tests need but you don't want hardcoded.

Creating a token

1. Tokens sub-tab → + Add Token.
2. Name (e.g. STRIPE_TEST_KEY, LOGIN_USER, BYPASS_TOKEN).
3. Value (encrypted with AES-256 at rest, never displayed after save).
4. Whether it's a secret. Secrets are masked in logs and the audit trail.
5. Save.

Using a token in tests

Reference with double-curly syntax:

// In a Fill step:
field: '#email'
value: '{{LOGIN_USER}}'

// In an API request:
url: 'https://api.example.com/v1/orders'
headers: { Authorization: 'Bearer {{API_KEY}}' }

The runtime substitutes values just before the step runs. Substitution failures (token doesn't exist) fail the step with a clear error, not a silent empty string.

Common tokens to define

• LOGIN_USER, LOGIN_PASSWORD — referenced by the login script.
• BYPASS_TOKEN — for skipping anti-bot middleware on staging.
• STRIPE_TEST_CARD — 4242 4242 4242 4242 for test checkouts.
• API_KEY — for API-request steps.
• FEATURE_FLAG_OVERRIDE — for forcing a feature on during a test.

Cookies

Pre-auth cookies let tests skip the login flow entirely — particularly useful when login is slow, multi-factor, or third-party (OAuth, SAML).

Capturing cookies

1. Sign into your app in a real browser.
2. Open DevTools → Application → Cookies.
3. Copy the session cookie (often named session, sid, auth, __Secure-next-auth.session-token).
4. In AegisRunner Cookies sub-tab → + Add Cookie.
5. Paste the name, value, domain, path, and flags (Secure, HttpOnly, SameSite).

The scanner / runner injects these before navigating, so the first request lands authenticated.

Caveats

• Cookies expire — refresh periodically when they stop working.
• If your app rotates session IDs on every sign-in, cookies don't help; use a login script instead.
• Domain matters. Cookies for auth.example.com won't apply when the scanner visits app.example.com.

Headers

Custom HTTP headers applied to every request from AegisRunner's browser. Common uses:

• X-Debug-Mode: true — your app shows extra debug UI for tests.
• X-AegisRunner: true — tag traffic in your logs/analytics so you can filter test traffic out.
• User-Agent override — match a specific UA for spoof testing.
• X-Bypass-Cache: true — defeat CDN cache during testing.

Login script

A Playwright script that runs before any test or scan, ensuring the session is established. Use this when:

• Your app's login is interactive (multi-factor, redirects, OAuth).
• Cookies expire too fast to maintain manually.
• Your auth flow has multiple steps and conditions.

Templates

Pick a starting point from the dropdown:

• Basic — username + password form.
• Google OAuth — handles the redirect to accounts.google.com.
• Microsoft SSO — Entra/Azure AD redirect.
• Auth0 — handles the auth0.com redirect.
• Okta — Okta SSO flow.

Anatomy of a login script

// Basic username/password
await page.goto(startUrl + '/login');
await page.fill('input[name="email"]', '{{LOGIN_USER}}');
await page.fill('input[name="password"]', '{{LOGIN_PASSWORD}}');
await page.click('button[type="submit"]');
await page.waitForURL('**/dashboard');

Tokens are substituted just before the script runs. Update the selectors and waits to match your actual login form.

When the login script runs

• At the start of every scan.
• At the start of every test run.
• On auto-login fallback — if any step is redirected to /login mid-test, AegisRunner re-runs the login script. Disable per-test by tagging with negative, unauthenticated, or a *-negative tag.

Form test data sets Pro+

For tests that submit forms with varying inputs, define a test data set — a row-based table of inputs to drive multiple test runs:

email	name	plan	expectedToast
alice@test.com	Alice	starter	Welcome, Alice
bob@test.com	Bob	pro	Welcome, Bob
charlie@test.com	Charlie	business	Welcome, Charlie

The same test runs once per row, with each row's values filling the form fields and assertions. Useful for boundary tests and full-form-coverage scenarios.

Manage under Test Data → Form Data Sets. CSV import supported.

Environments and overrides Pro+

Pro and Business plans support multiple environments per project — staging, preview, production. Each environment can have its own:

• Tokens (e.g. different API keys for staging vs prod).
• Cookies.
• Headers.
• Login script (different SSO config).
• Base URL override.

Pick the environment when starting a scan or run. Test data substitution uses the active environment's values.

Security model

• Token values are AES-256 encrypted at rest.
• Token values are never displayed in the UI after save (only the name and a "last updated" timestamp).
• Token values are masked in run logs ({{LOGIN_PASSWORD}} → ****).
• Adding/editing/deleting tokens is logged in the audit trail (Pro+).
• Project Members can use tokens but not view their values; only Admins and Owners can edit.

Common questions

My token isn't being substituted.

Check the case — token names are case-sensitive. Confirm the token exists for the active environment if you're using Pro+ environments.

How do I rotate a token without downtime?

Edit the value. The next run picks up the new value automatically. Tests in progress continue with the old value.

Can I share tokens across projects?

No — tokens are project-scoped by design. If you have many projects sharing the same key, copy and paste; we may add cross-project tokens in the future for SSO/Enterprise.

Why aren't my pre-auth cookies working?

Common causes: domain mismatch, expired cookie, your app rotates the session ID on every sign-in. Check the run log for the cookie injection step; if your app issues a fresh cookie on first request, you need a login script.

Related

• Managing Projects — environments and Project Config overview.
• API Testing — using tokens in API steps.
• Debugging Failed Tests — auth failures.