Environment Setup in ReAPI

ReAPI’s environment management is designed to simplify and centralize test configurations, making it more structured and explicit than traditional variable-based solutions. Unlike platforms where all environment settings depend solely on variables, ReAPI introduces Servers, Authorization, and Variable Groups as distinct components, making key configurations easier to manage and reference.

Key Components of Environment Setup in ReAPI

Servers (Endpoints)

Servers define the base URLs for API requests, eliminating the need to manually prefix API URLs with a {{baseUrl}} variable.
Each server has a readable name and a variable as its value, allowing dynamic updates when switching environments.
You can configure different services (e.g., User Service, Order Service) with their own base URLs under each environment.

Authorization

Authorization settings (e.g., Bearer tokens, Basic Auth, Custom Auth) are managed at the environment level.
Just like servers, authorization configurations support variables, ensuring dynamic token management across environments.
This separation makes it easy to configure authentication globally without manually setting authorization headers for each request.

Variable Groups

Variable Groups store environment-specific values such as service URLs, authorization tokens, and any other reusable configurations.
ReAPI supports nested variable groups, meaning child groups inherit variables from their parent groups.
This is especially useful for role-based testing. For example, under the Production environment, you can create subgroups for different user roles:
- Admin Group: Uses an admin token.
- User Group: Uses a regular user token.
- This setup enables quick role-switching without redefining all variables.

Example Environment Setup

Here’s an example configuration in ReAPI, demonstrating how to structure servers, authorization, and variable groups.

Servers Configuration

servers:
  userService:
    name: "User Service"
    url: { { userServerUrl } }
  orderService:
    name: "Order Service"
    url: { { orderServerUrl } }
  deliveryService:
    name: "Delivery Service"
    url: { { deliveryServerUrl } }

Authorization Configuration

authorization:
  type: "bearer"
  token: { { bearerToken } }

Variable Groups (Per Environment)

# Dev Environment
dev:
  userServerUrl: "https://dev.api.example.com/user"
  orderServerUrl: "https://dev.api.example.com/order"
  deliveryServerUrl: "https://dev.api.example.com/delivery"
  bearerToken: "devBearerTokenValue"
 
# Staging Environment
staging:
  userServerUrl: "https://staging.api.example.com/user"
  orderServerUrl: "https://staging.api.example.com/order"
  deliveryServerUrl: "https://staging.api.example.com/delivery"
  bearerToken: "stagingBearerTokenValue"
 
# Production Environment
production:
  userServerUrl: "https://api.example.com/user"
  orderServerUrl: "https://api.example.com/order"
  deliveryServerUrl: "https://api.example.com/delivery"
  bearerToken: "prodBearerTokenValue"

How This Setup Works

Servers: Each service (User, Order, Delivery) is assigned a readable name and a variable-based URL.
Authorization: A bearer token is set globally using a variable, making environment switching seamless.
Variable Groups:
- Each environment (dev, staging, production) maintains its own set of variables.
- If a new role (e.g., “Admin” or “User”) needs different credentials, you can inherit from the base group instead of duplicating values.

Why This Approach?

ReAPI’s explicit separation of servers, authorization, and variable groups improves:

Readability – Key configurations are clearly named and easy to reference.
Reusability – Environment variables inherit values where needed, reducing duplication.
Maintainability – Changing a URL or token for an environment requires only one update, rather than modifying every test case.

This structured approach ensures consistency, reduces manual setup, and makes managing environments for testing effortless and scalable.

Important Prerequisites Planning