Practical Guide: A Recommended Environment Setup

This guide walks through a typical, recommended environment configuration that every test team should consider as a starting point. The example provided is a powerful reference for managing multiple microservices and user roles, but you should adapt it to suit your specific project requirements.

The Scenario

Imagine a common scenario where your application is composed of several microservices and needs to be tested with different user permissions.

Services: Auth Server, User Server, and Order Server.
Authentication: All services use a single Bearer Token for authentication.
Environments: We need to run tests against Staging.
User Roles: We need to test the system as both an Admin User and a Normal User.

Step 1: Define the Logical Servers

First, we define our servers as logical, named entities. Their actual URLs will be provided by variables, which keeps our tests clean and stable.

Name: Auth Server
- Value: {{auth_url}}
Name: User Server
- Value: {{user_url}}
Name: Order Server
- Value: {{order_url}}

Step 2: Define the Authentication Profile

Next, we create a named authentication profile. The token itself is also a variable, so it can be switched out easily for different users and environments.

Name: Service API Token
- Type: Bearer Token
- Token: {{api_token}}

Step 3: Structure Variable Groups with Inheritance

This is where the power of ReAPI’s design comes into play. To manage our different environments and user roles, we’ll use a clean, repeatable pattern of nested variable groups.

The strategy is to create one “base” parent group for each environment (Development, Staging, Production) that contains the common server URLs. Then, for each environment, we create child groups for the user roles that inherit from the corresponding base.

Staging Environment Example

Let’s look at the Staging environment in detail.

Parent Group: Staging - Base This group defines all the common configurations for Staging.

{
  "auth_url": "https://auth.staging.myapi.com",
  "user_url": "https://users.staging.myapi.com",
  "order_url": "https://orders.staging.myapi.com"
}

Child Group 1: Staging - Admin User This group inherits from Staging - Base and only provides the admin-specific api_token.

Inherits From: Staging - Base

Variables:

{
  "api_token": "staging-token-for-admin-user"
}

Child Group 2: Staging - Normal User This group also inherits from Staging - Base and provides the token for a regular user.

Inherits From: Staging - Base

Variables:

{
  "api_token": "staging-token-for-normal-user"
}

Completing the Setup for Other Environments

You would then repeat this parent/child pattern for your other environments.

Development Environment Groups:

Parent: Development - Base

{
  "auth_url": "https://auth.dev.myapi.com",
  "user_url": "https://users.dev.myapi.com",
  "order_url": "https://orders.dev.myapi.com"
}

Child: Development - Admin User (Inherits from Development - Base)
```
{ "api_token": "dev-token-for-admin-user" }
```
Child: Development - Normal User (Inherits from Development - Base)
```
{ "api_token": "dev-token-for-normal-user" }
```

Production Environment Groups:

Parent: Production - Base

{
  "auth_url": "https://auth.api.myapi.com",
  "user_url": "https://users.api.myapi.com",
  "order_url": "https://orders.api.myapi.com"
}

And so on for Production user roles (e.g., Production - Admin User which would provide a production-safe token).

Putting It All Together: The Workflow

With this structure, your testing workflow becomes incredibly efficient.

Configure Your Test: In your test case, you set the API step to use the User Server and the Service API Token.
Run as Admin: To test admin functionality, you simply select Staging - Admin User as your active variable group. ReAPI automatically inherits the staging URLs from Staging - Base and uses the admin token.
Run as Normal User: To run the exact same test as a normal user, you just switch the active variable group to Staging - Normal User. ReAPI again inherits the URLs but now uses the normal user’s token.

This pattern keeps your configuration DRY (Don’t Repeat Yourself) and makes switching between test contexts trivial. If a server URL ever changes, you only need to update it in one place (Staging - Base), and all user role configurations will be instantly updated.

Sensitive Data Masking Introduction