> ## Documentation Index
> Fetch the complete documentation index at: https://jetify-dependabot-npm-and-yarn-npm-and-yarn-387f502f5a.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Parameterizing Tests with Environment Variables

> Make tests flexible and reusable with environment variables. Run the same tests across staging, development, and production environments.

## Using Environment Variables in Tests[​](#using-environment-variables-in-tests "Direct link to Using Environment Variables in Tests")

You can include environment variables in your test files using the format
`${ENV_VAR_NAME:-default_value}`. Testpilot will automatically expand these variables when running
your tests.

The syntax works as follows:

* `${ENV_VAR_NAME}` - Uses the value of the environment variable
* `${ENV_VAR_NAME:-default_value}` - Uses the value of the environment variable if set, otherwise
  uses the default value

## Example: Parameterizing Host URLs[​](#example-parameterizing-host-urls "Direct link to Example: Parameterizing Host URLs")

A common use case is parameterizing the host URL in your tests. This lets you run the same tests
against different environments without modifying your test files:

```yaml theme={null}
name: "Parameterized URL Test"
context:
  - text: "Test can run against different environments based on the TEST_HOST environment variable"
cases:
  - id: "login-test-001"
    name: "User Login Test"
    description: "Test user login functionality across different environments"
    url: "${TEST_HOST:-https://staging.example.com}/login"
    steps:
      - "Navigate to the login page"
      - "Enter valid username and password"
      - "Click the login button"
      - "Verify successful login"
```

In this example:

* If `TEST_HOST` is set (e.g., `export TEST_HOST=https://dev.example.com`), the test will use that
  value
* If `TEST_HOST` is not set, it will fall back to the default value `https://staging.example.com`

## Running Tests with Different Parameters[​](#running-tests-with-different-parameters "Direct link to Running Tests with Different Parameters")

You can run the same test with different parameter values by changing the environment variables:

```bash theme={null}
# Run against staging (default)
testpilot test login.pilot.yaml

# Run against development
export TEST_HOST=https://dev.example.com
testpilot test login.pilot.yaml

# Run against production
export TEST_HOST=https://example.com
testpilot test login.pilot.yaml
```

## Parameterizing Other Test Values[​](#parameterizing-other-test-values "Direct link to Parameterizing Other Test Values")

You can parameterize any string value in your test files, not just URLs:

```yaml theme={null}
name: "User Registration Test"
context:
  - text: "Test registration with configurable user details"
cases:
  - id: "registration-001"
    name: "New User Registration"
    description: "Test new user registration process"
    url: "https://${TEST_HOST:-example.com}/register"
    steps:
      - "Fill in the registration form with email: ${TEST_EMAIL:[email protected]}"
      - "Set password to: ${TEST_PASSWORD:-SecurePass123!}"
      - "Complete registration and verify success"
```

## Use Cases for Parameterized Tests[​](#use-cases-for-parameterized-tests "Direct link to Use Cases for Parameterized Tests")

Parameterizing your tests is useful for:

1. **Environment Switching**: Run the same tests against dev, staging, and production
2. **Configuration Changes**: Test with different feature flags or settings
3. **Test Data Variation**: Use different test accounts or input data
4. **CI/CD Integration**: Configure tests differently based on the build environment
5. **Local Development**: Allow developers to point tests to their local instances

## Example in CI/CD Pipeline[​](#example-in-cicd-pipeline "Direct link to Example in CI/CD Pipeline")

Here's how you might use parameterized tests in a CI/CD pipeline:

```yaml theme={null}
# In your CI/CD configuration
stages:
  - test

test_staging:
  stage: test
  script:
    - export TEST_HOST=https://staging.example.com
    - testpilot test tests/*.pilot.yaml

test_production:
  stage: test
  when: manual # Only run when triggered manually
  script:
    - export TEST_HOST=https://example.com
    - testpilot test tests/*.pilot.yaml
```

## Best Practices[​](#best-practices "Direct link to Best Practices")

When parameterizing your tests:

1. **Always provide defaults**: Use the `:-default_value` syntax to ensure tests work even without
   environment variables set
2. **Document parameters**: Include comments or context that explains what parameters are available
3. **Use descriptive names**: Choose environment variable names that clearly indicate their purpose
4. **Group related parameters**: Keep related parameters together (e.g., `TEST_HOST`, `TEST_PORT`,
   `TEST_PROTOCOL`)

By parameterizing your tests, you create more flexible and maintainable test suites that can easily
adapt to different environments and configurations.