Skip to main content

​
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​

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: 
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​

You can run the same test with different parameter values by changing the environment variables: 
# 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​

You can parameterize any string value in your test files, not just URLs: 
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​

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​

Here’s how you might use parameterized tests in a CI/CD pipeline: 
# 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​

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.
⌘I