Configurable Variables Resolved Before Test Setup: ballerina/test setEnv and Config.toml Precedence

Answer

Calling test:setEnv after a module that contains a configurable has been loaded does **not** change the resolved value. The variable is fixed during module initialization, and later environment‑variable changes have no effect.

Confirmed Facts

1. Resolution order during module initialization: system properties (‑D) → environment variables → Config.toml (or Config.yaml) → default values.
2. If both an environment variable and a Config.toml entry exist for the same key, the environment variable wins.
3. To influence a configurable via test:setEnv, the environment variable must be set **before** the module is first imported.

Steps for Credential‑Free Integration Tests

1. In a static @test:BeforeSuite block, call test:setEnv for each required key (or ensure the variables are already set in the process environment).
2. Import the module under test **after** the setEnv calls, e.g., inside a test function or a @test:BeforeEach that runs after the suite‑level setup.
3. If you prefer a file‑based approach, place a test‑specific Config.toml in the test resources directory and ensure no conflicting environment variables are present (otherwise the env var will override it).
4. Run the test; the configurable will resolve to the value supplied by the setEnv call or the test Config.toml.

Missing Diagnostic Detail

If you observe that a configurable still returns a production value despite using test:setEnv in @test:BeforeSuite, verify whether any dependency or test utility imports the module before your suite block runs. Identifying the earliest import point determines whether the environment variable was set early enough.