Overview

Core capabilities

OrbitTest covers browser lifecycle, test discovery, parallel execution, retries, intent-first element resolution, screenshots, traces, structured reports, and CI output. The goal is to make the first useful test quick while still supporting deeper QA workflows as the suite grows.

The browser runner uses Chrome DevTools Protocol, so tests can collect browser-level information such as console errors, failed network requests, page title, URL, screenshots, and timeline evidence. That makes failures easier to investigate than a plain assertion error.

How the pieces fit together

A test file imports the public API, the CLI discovers matching tests, Mission Control schedules runs, a fresh browser profile is created for isolation, and the Surface layer resolves visible user intent to DOM targets. Reports are written at the end of the run.

For Android, Orbittest Studio and the mobile provider use ADB and UIAutomator directly. This avoids Appium server setup for Android-only QA workflows and keeps local evidence close to the test runner.

When to use each surface

Use the CLI for repeatable browser automation and CI. Use the local UI or reports when you need to inspect failures. Use Studio when the work is Android-focused and you want the device mirror, UI hierarchy, logcat, and test editor in one place.

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.