Quick Start

Create the project files

Run the init command from the project root. It creates a config file, a test directory, and an example test that demonstrates the basic shape of an OrbitTest flow.

Write one meaningful test

A useful first test should cover a real route or workflow: home page loads, login form appears, search returns results, or checkout reaches a confirmation page. Avoid starting with a large suite. One stable smoke test is better than ten vague checks.

Read the report

After the run, open the HTML report. Confirm that the test name, status, duration, and artifacts are easy to understand. This habit matters because reports are what your team will read when CI fails.

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.