Skip to content

Roadmap

OrbitTest is currently in an architecture cleanup freeze: large new features are paused while existing features are reorganized into clearer modules. That sounds unglamorous, but it is the work that decides whether a tool is still pleasant to use three years from now. Bug fixes and stability work continue throughout.

The honest status of each feature area is maintained on the Overview page, stable features are safe to build on today, and this page describes where each area is headed.

  • Clearer diagnostics: when a locator fails, the error should explain what was tried, what almost matched, and what to do about it.
  • Stronger locator explanations, especially for ambiguity (“3 elements matched; here they are”).
  • Better parallel scheduling, so large suites use workers more evenly.
  • Richer report filtering for long runs.

The Android provider is in Phase 1: the API documented on the Mobile Test API page works and is shipping, and the surface will keep growing. Planned work centers on:

  • Studio workflow polish, fewer clicks between editing, running, and reviewing evidence.
  • Stronger Android evidence capture around the failing step.
  • Better device state handling: lock screens, permission dialogs, low battery, the realities of physical devices.
  • Smoother Companion setup, particularly on vendor Android builds with extra install gates.
  • Authenticode signing for the Studio installer, replacing the SmartScreen + hash-check flow with a normal signed install.
AreaStatusShape of the plan
API testingPlannedFirst-class HTTP request/assertion support, so journey tests can verify backend effects without a second tool.
Visual assertionsExperimental todayRicher region-based comparison and better cross-environment stability.
DashboardsExploringMore views in the local UI; trend data across runs.
IntegrationsExploringMore CI artifact and team-reporting integrations beyond JUnit and annotations.
iOSNot planned short-termThe ADB/UIAutomator approach is Android-specific; iOS would be a separate effort and is not on the current roadmap.

Will the architecture cleanup break my tests?

Section titled “Will the architecture cleanup break my tests?”

The public API, test, expect, the orbit methods, config, is the stable contract. Cleanup work reorganizes internals behind that contract.

It is planned but unscheduled; the experimental flag experimental.apiTesting exists in config as the future switch. Watch the release notes.

Open or upvote a GitHub issue describing your concrete use case. “We run 400 Android tests nightly and need X” moves things; abstract feature requests less so.

  • Overview — Feature status, how a test run works from CLI to report, and which OrbitTest surface to use for each job.
  • Architecture — The seven internal modules, how a click travels from your test to the browser, and how the Android stack swaps in.
  • Contributing — How to propose changes, write bug reports that get fixed, follow the code standards, and report security issues privately.
  • Mobile Testing — Android automation with ADB and UIAutomator through @orbittest/mobile: setup, configuration, hybrid tests, and evidence.