How do you handle configuration, multiple environments and secrets in a test framework?

Configuration problems show up as “works on my machine” failures and as leaked credentials. The design goal is that the same test code runs against any environment by changing one value, and that no secret ever lives in the repository.

What belongs in configuration

• Base URLs for UI and APIs, per environment.
• Browser, headless mode, viewport, timeouts.
• Feature toggles relevant to tests, tenant identifiers.
• Credentials and API keys (as secret references, not values).

Anything that differs between local, CI, staging and pre-production belongs here, not in test code.

Precedence order

I use a layered model where later sources override earlier ones:

1. Defaults in code or a base file.
2. Environment file chosen by one variable, for example TEST_ENV=staging loads config/staging.yaml.
3. Environment variables for CI and secrets.
4. Command-line or system properties for one-off overrides (-Dbrowser=firefox).

Document this order in the README; ambiguity about which value won is a common source of confusion.

A single typed config object

Tests should never call System.getenv scattered across the codebase. Load once, validate, and expose typed values:

public record TestConfig(String baseUrl, String apiUrl, Duration timeout, String adminPassword) {

    public static TestConfig load() {
        String env = System.getProperty("env", System.getenv().getOrDefault("TEST_ENV", "local"));
        Properties p = new Properties();
        try (InputStream in = TestConfig.class.getResourceAsStream("/config/" + env + ".properties")) {
            if (in == null) throw new IllegalStateException("No config for environment: " + env);
            p.load(in);
        } catch (IOException e) {
            throw new UncheckedIOException(e);
        }
        return new TestConfig(
            override("BASE_URL", p.getProperty("baseUrl")),
            override("API_URL", p.getProperty("apiUrl")),
            Duration.ofSeconds(Long.parseLong(override("TIMEOUT_SECONDS", p.getProperty("timeoutSeconds", "10")))),
            required("ADMIN_PASSWORD"));
    }

    private static String override(String envVar, String fallback) {
        return System.getenv().getOrDefault(envVar, fallback);
    }

    private static String required(String envVar) {
        String v = System.getenv(envVar);
        if (v == null || v.isBlank()) throw new IllegalStateException("Missing required secret: " + envVar);
        return v;
    }
}

Failing fast with a clear message beats fifty tests timing out against null/login.

Secrets

• Never commit them, not even for test environments. Add secrets scanning to catch accidents.
• Inject at runtime from the CI system’s secret store (GitHub Actions secrets, Jenkins credentials binding) or a vault such as HashiCorp Vault or a cloud secret manager.
• Locally, use a git-ignored .env file or the developer’s own vault access, with a checked-in .env.example listing required names.
• Mask in logs and reports. Be careful with request logging filters and screenshots that might capture tokens.
• Least privilege and rotation: dedicated test accounts with only the permissions tests need, rotated regularly.

- name: Run API tests
  env:
    TEST_ENV: staging
    ADMIN_PASSWORD: ${{ secrets.STAGING_ADMIN_PASSWORD }}
  run: mvn -B test

What interviewers look for

• One switch to change environment, with no hard-coded URLs in tests.
• A defined override order.
• A credible secrets story covering CI, local development and logs.
• Fail-fast validation of configuration.

Common mistakes

• A config.properties with production passwords committed “temporarily”.
• Environment checks such as if (env.equals("prod")) scattered inside tests.