Managing API Test Environments and Configurations in ACCELQ

A critical requirement for any successful automation suite is the ability to run the same test scripts across multiple deployment environments (e.g., Development, QA, Staging, Production) without modifying the test logic. This is achieved by externalizing environment-specific values like URLs and credentials from your scripts.

This article outlines the best practices for managing such configurations in ACCELQ using Global Properties and Run Properties.

The Problem: Hardcoded Configurations

A common mistake is to hardcode environment values directly into test steps.

An example of what NOT to do:

Invoke ReSTful GET service. End-point: 'https://api-qa.myapp.com/v2/users/123'

Define ReST connection name: 'auth_conn', base URL: 'https://auth-qa.myapp.com', authentication headers (comma separated): 'api-key=super-secret-qa-key'

This approach is problematic because:

• It's not scalable: To run this test against a Staging environment, you must manually find and replace the URL and API key.
• It's error-prone: Manual changes increase the risk of typos and mistakes.
• It's insecure: Sensitive data like API keys are exposed directly in the test logic, visible in version control and reports.

The Solution, Part 1: Centralize with Global Properties

The first step is to abstract all environment-specific values into Global Properties. Think of these as centralized constants that your tests can reference.

Define Your Properties

In ACCELQ, you would define Global Properties for each value that might change between environments.

• API_BASE_URL
• AUTH_URL
• API_KEY

Build Generic Tests

Now, modify your test logic to reference these properties instead of using hardcoded values. ACCELQ uses the {prop: property_name} syntax to reference a Global Property.

A "good" example of a generic test:

Invoke ReSTful GET service. End-point: '{prop: API_BASE_URL}/v2/users/123'

Define ReST connection name: 'auth_conn', base URL: '{prop: AUTH_URL}', authentication headers (comma separated): 'api-key={prop: API_KEY}'

This test script is now generic and no longer tied to a specific environment.

The Solution, Part 2: Override at Runtime with Run Properties

Now that your tests are generic, you can use Run Properties to tell them which environment to target for a specific execution. Run Properties are set when you trigger a test run and will override the default values of Global Properties if the names match.

This creates a powerful, layered configuration system:

1. Set Default Values: Your Global Properties can hold the default values, typically for your primary test environment (e.g., QA).
   • API_BASE_URL (default value): https://api-qa.myapp.com
   • API_KEY (default value): qa-default-key
2. Configure Environment-Specific Runs: When you configure a new Test Run in ACCELQ, you can provide Run Properties to target a different environment, like Staging. For your "Staging Test Run," you would set the following Run Properties:
   • API_BASE_URL = https://api-staging.myapp.com
   • API_KEY = staging-super-secret-key
3. Execute the Test: When you execute the "Staging Test Run," ACCELQ will see the Run Properties for API_BASE_URL and API_KEY. It will use these "Staging" values instead of the default "QA" values from the Global Properties. The exact same test script now runs successfully against your Staging environment.

Best Practices

• Security: When creating Global Properties for sensitive data like passwords or API keys, always mark them as "Encrypted". This ensures the values are masked in all test reports and logs.
• Naming Conventions: Use a clear and consistent naming convention for your properties (e.g., APP_COMPONENT_PROPERTY) to keep them organized as your project grows.
• CI/CD Integration: This approach is ideal for CI/CD pipelines. Your Jenkins, Azure DevOps, or other CI tool can pass in the Run Properties as command-line arguments, allowing for fully automated and environment-aware test execution.