Skip to main content

First-Class Environments

retestr.ai allows you to define and manage multiple Environments (e.g., Staging, Production, Dev) to run your tests against different deployments without changing your test scripts.

Why use Environments?​

Testing often happens in stages. You might want to:

  1. Run your full suite against staging.myapp.com to catch regressions before release.
  2. Run a smoke test against myapp.com (Production) after deployment.
  3. Run specific tests against localhost:3000 during development.

Hardcoding URLs like await page.goto('https://staging.myapp.com') makes this impossible. Environments solve this by injecting configuration variables into your test runs.

Managing Environments​

To configure environments, navigate to Settings > Environments.

You can create environments with a Name and a JSON Configuration object.

Example Configuration​

Staging Environment:

{
  "baseURL": "https://staging.myapp.com",
  "apiEndpoint": "https://api-staging.myapp.com",
  "user": "test-user-staging",
  "password": "staging-password"
}

Production Environment:

{
  "baseURL": "https://myapp.com",
  "apiEndpoint": "https://api.myapp.com",
  "user": "test-user-prod",
  "password": "prod-password"
}

Using Environments in Tests​

When you run a test with a specific environment selected, the JSON configuration is automatically injected into the test context.

Accessing Configuration​

In your Playwright script, you can access these values via the standard Playwright config or environment variables, but retestr.ai makes it even easier by merging them into the browser context options.

If you defined baseURL in your environment config, Playwright uses it automatically:

// This will go to https://staging.myapp.com or https://myapp.com
// depending on the active environment.
await page.goto('/');

For custom variables (like API keys or users), they are injected into the test configuration. Currently, the Runner handles baseURL and viewport natively if provided in the top-level of the JSON.

(Note: Future updates will expose arbitrary config keys via process.env or a global helper.)

Enabling Environments for Tests​

You can assign specific environments to Test Cases or Test Suites.

  1. Open a Test Case.
  2. In the Settings panel, find the Environments section.
  3. Select the environments you want to enable for this test.

When you trigger a run for this test, the Runner will execute it once for each selected environment.

For example, if you select "Staging" and "Production", triggering the test will spawn two jobs:

  1. Test X running against Staging.
  2. Test X running against Production.

This ensures you have separate baselines and history for each environment.

Best Practices​

  • Use Relative URLs: Always write your tests using relative URLs (e.g., page.goto('/login')) and rely on the Environment's baseURL.
  • Separate Baselines: retestr.ai automatically maintains separate baseline images for different environments if you configure your CI/CD to pass the environment name as part of the branch or context (or by relying on the Runner's environment isolation).