Environment Management in ReAPI

Environments are the heart of reusable and reliable API testing. They allow you to run the same test logic against different configurations (like development, staging, or production) without ever modifying the tests themselves. ReAPI’s environment system is designed to be both powerful and intuitive, addressing the common challenges of configuration management head-on.

The Core Components

Instead of relying on a flat list of variables, ReAPI organizes your environment configuration into three distinct, manageable components.

1. Servers

A Server is a named reference to a base URL. This abstraction is key to making your tests stable and easy to maintain.

• Before (Brittle): POST {{user_api_endpoint}}/v1/users
• With ReAPI (Robust): A test step is configured to use the User API server.

You can create a server named User API with the value https://user-api.dev.example.com. If you need to rename the User API server to Primary User Service, you can do so without breaking any tests because the tests are linked to the server’s stable identity, not its name.

2. Authentication

Authentication profiles are named, reusable credentials. You can configure different authentication methods (like Basic Auth, Bearer Tokens, and custom API Keys) and give them a clear name, like Admin Token or Guest Key.

Tests refer to these profiles by name, so you can update a token or password in one central place, and every test that uses it will get the update automatically.

3. Variable Groups

Variable Groups are sets of key-value pairs specific to an environment. This is where you store dynamic values that change between environments, such as:

• Hostnames (baseUrl: "https://api-staging.example.com")
• Test-specific IDs (testUserId: "staging-user-456")
• Configuration flags (featureToggles: { "newCheckout": true })

Variable Groups also support nesting, allowing you to create parent-child relationships. A child group inherits all the variables from its parent, making it easy to share common configurations (like server URLs) while overriding or adding specific values (like user tokens) in the child. This is a powerful way to manage variations, such as different user roles within the same environment.

The Layered Model: How It All Works Together

The power of ReAPI’s system comes from how these three components work together in a layered model that combines stability with flexibility.

1. Tests Refer to Stable Names: Your API test steps are configured to use a named Server (e.g., Payment API) and a named Authentication profile (e.g., Merchant Key). These references rarely change.
2. Server/Auth Values are Dynamic: The value of the Payment API server can be defined using a variable, like {{gateway_url}}.
3. Variable Groups Provide the Values: You create a separate Variable Group for each environment.
   • Staging Group: { "gateway_url": "https://payments.staging.co" }
   • Production Group: { "gateway_url": "https://payments.api.co" }

To run your tests against production instead of staging, you simply switch the active Variable Group. ReAPI then resolves the correct gateway_url for the Payment API server at runtime. Your tests remain unchanged.

Configuration Hierarchy: Which Setting Gets Used?

ReAPI offers multiple levels of configuration to handle everything from simple test cases to complex, multi-environment integration suites. When settings conflict, ReAPI uses a clear “most specific wins” hierarchy.

Here is the order of priority, from highest to lowest:

1. API Step Level (Highest Priority)

   • What: A Server or Auth config set on an individual API node within a test case.
   • Use Case: Overriding the default for a single, exceptional request. For example, your entire test flow uses the Main API server, but one step needs to call a separate Auth Service to refresh a token.

2. Selector Node Level

   • What: Configuration applied to a Selector node inside a Test Runner.
   • Use Case: Running a specific group of tests against a different environment than the rest of the runner. For example, in a single run, you could have one selector for “Regression Suite” pointing to staging and another selector for “Smoke Tests” pointing to production.

3. Test Runner Level

   • What: A global configuration applied to an entire Test Runner.
   • Use Case: This is the most common place to define the environment for a test suite. Setting the configuration here ensures all test cases included in the run use the same environment by default, overriding their individual settings.

4. Test Case Level (Lowest Priority in a Run)

   • What: The default Server, Auth, and Variable Group saved with a Test Case.
   • Use Case: This setting is primarily used when you are designing or debugging a single test case by running it on its own. When a test case is included in a Test Runner, its configuration is typically overridden by the runner’s settings.

Best Practices

• Define Defaults at the Runner Level: For most test suites (regression, smoke), set your desired environment at the Test Runner level for clarity and consistency.
• Use Selector Overrides for Mixed Scenarios: Only use Selector-level configuration when you have a clear need to run different test suites against different environments in the same execution.
• Reserve API Step Overrides for Exceptions: Avoid setting the server or auth on every single API step. Rely on the defaults from the runner or test case, and only override for true one-off calls to different services.

Next Steps

For a detailed walkthrough of how to apply these concepts to a real-world scenario, see our guide: Practical Guide: A Recommended Environment Setup.