Environment Variables

Why environment variables matter

Environment variables let CI and local machines configure paths, sharding, device selection, and browser behavior without changing committed test files.

Browser variables

`ORBITTEST_CHROME_PATH` points the runner at a specific Chrome or Chromium executable. This is useful on CI images, locked-down developer machines, or custom browser builds.

CI and Android variables

`CI`, `GITHUB_ACTIONS`, `ORBITTEST_SHARD`, `ADB_PATH`, and `DEVICE_SERIAL` help the same command adapt to automation environments and connected devices.

Reference table

Practical checklist

• Keep the workflow readable enough that a QA engineer, developer, or product teammate can understand the intent without opening application source code.
• Prefer user-visible names, stable configuration, and clear evidence over hidden assumptions or brittle implementation details.
• Run the smallest useful check locally before adding it to CI, then verify that failures produce screenshots, logs, traces, or reports that explain what happened.
• Review this part of the suite regularly so outdated examples, stale setup, and obsolete workarounds do not reduce trust in the automation.

Common mistakes to avoid

• Do not add automation only to increase test count. Each page and test should protect a clear user journey, release risk, or debugging need.
• Do not hide important behavior inside helpers so deeply that the test no longer explains what the user is doing.
• Do not rely on fixed sleeps when the application can expose a meaningful ready state such as visible text, URL change, element availability, or completed evidence capture.
• Do not ignore failing artifacts. A report, screenshot, trace, or log entry should feed back into better product code, better waits, or clearer test data setup.