Skip to content

Introduction

OrbitTest is an end-to-end testing framework for websites and Android apps. You write tests in plain JavaScript, and OrbitTest drives a real Chrome browser (or a real Android phone) the same way a person would: it opens pages, clicks buttons, types into fields, and checks that the right things appear on screen.

The part that makes OrbitTest different is how you point at things on the page. Most testing tools make you hunt through the HTML for CSS selectors like #root > div.col-3 > button.btn-primary. OrbitTest works the other way around. You tell it what the user can see:

await orbit.click("Login");
await orbit.type("Email", "user@example.com");
expect(await orbit.hasText("Dashboard")).toBe(true);

A test that reads like the instructions you would give a person.

If a developer renames a CSS class but the button still says “Login”, nothing changed for the user, and your test keeps passing. That single idea, test what users see, not what developers write, shapes the whole framework.

A useful end-to-end test setup needs more than a click function. OrbitTest ships the surrounding machinery so you do not have to build it yourself:

  • Browser lifecycle: a clean Chrome profile per test, started and cleaned up automatically.
  • Test discovery: drop files matching *.test.js or *.spec.js into a tests/ folder and they run.
  • Parallel workers, retries, and per-test timeouts.
  • HTML, JSON, and JUnit reports with screenshots, traces, and failure diagnostics.
  • A CI mode built for GitHub Actions, Jenkins, GitLab CI, and Azure DevOps, including sharding and flaky-test detection.
  • Android automation through ADB and UIAutomator, without an Appium server.

There is no build step and no TypeScript compiler requirement. Tests are plain CommonJS JavaScript files that run on Node.js 18 or later.

These docs assume you can write basic JavaScript and run commands in a terminal. That is it. You do not need prior experience with Selenium, Playwright, Cypress, or Appium. Where OrbitTest borrows an idea from those tools, the docs explain the idea from scratch.

If you are a QA engineer moving from manual testing into automation, start with the Quick Start and Test Basics. If you are a developer adding end-to-end coverage to an existing project, the Configuration and CI/CD Integration pages will matter most. If your work is Android-focused, jump to What is Studio?.

Think of every OrbitTest test as a short user story with evidence attached. The test opens a page, does what a user would do, waits for something meaningful to appear, and asserts on it. When it fails, the report should tell you which of three things happened:

  1. The application broke. The report shows a failed API call, a JavaScript error, or missing text.
  2. The environment broke. The device was offline, the test site was down, Chrome could not start.
  3. The test no longer describes the product. The button text changed, the flow was redesigned.

Everything in OrbitTest, traces, screenshots, Smart Report, logcat capture on Android, exists to make that three-way decision fast. A test suite that fails without explaining itself gets ignored, and an ignored test suite is worse than no test suite.

This site documents two related tools that share one testing API:

ProductWhat it isWhere it runs
OrbitTestThe test framework and CLI: orbittest run, reports, CI mode, the browser and mobile APIs.Any machine with Node.js 18+ (Windows, macOS, Linux)
Orbittest StudioA Windows desktop IDE for Android QA: live device mirror, UI inspector, logcat viewer, editor, and test runner in one app.Windows 10/11, 64-bit

You can use OrbitTest alone for browser testing. Studio is for teams doing Android work who want the device tooling and the editor in one place. Tests written in Studio are normal OrbitTest files, so nothing locks you into the desktop app.

Yes. OrbitTest is open source under the Apache License 2.0 and installs from npm. Orbittest Studio is distributed free for Windows under the MIT License.

OrbitTest drives Chromium-based browsers through the Chrome DevTools Protocol. It uses your system Chrome by default, or a custom build via the ORBITTEST_CHROME_PATH environment variable.

No. Most tests only use visible text, labels, and roles. CSS and XPath locators exist for the rare cases where text alone is ambiguous, and the docs show you when to reach for them.

Not today. Mobile support is Android-first, built on ADB and UIAutomator. See the Roadmap for what is planned.

  • Quick Start — Create a project with orbittest init, write and run a first browser test, and read the HTML report, in five short steps.
  • Installation — Install OrbitTest with npm, set up Chrome or a custom browser path, and verify the environment with orbittest doctor.
  • Test Basics — How to structure readable end-to-end tests: arrange-act-assert, the orbit object, per-test options, and strong assertions.
  • What is Studio? — Orbittest Studio explained: a Windows desktop IDE that puts device mirror, inspector, logcat, editor, and test runner in one app.