@testsigma/arcus-cli

Command-line tool for Testsigma script — the TypeScript DSL for writing end-to-end web, mobile, and API tests, running them through a local Testsigma agent, and pushing them to Testsigma.

Install

npm install -g @testsigma/arcus-cli

Requires Node.js 22 or newer.

Authenticate

testsigma login
testsigma whoami
testsigma auth-status
testsigma logout

Write a test

The CLI serves the DSL reference and worked examples for each application type (web, mobile, api), so they always match the installed version:

testsigma test reference --type web
testsigma test examples  --type web

Check a spec without executing it:

testsigma test validate --input tests/login.spec.ts

Use --project <dir> in place of --input to cover every spec in a directory. The two are mutually exclusive.

Run a test

Local runs go through the Testsigma agent, which owns the browser and device inventory. Every run states where it executes — --local or --cloud, never inferred from config, because a run reaches a real browser or device:

# web — Chrome for Testing by default
testsigma test run --local --input tests/login.spec.ts
testsigma test run --local --input tests/login.spec.ts --browser firefox --headless

# mobile — pass a connected device and its capabilities
testsigma test run --local --input tests/app.spec.ts \
  --device <device-id> \
  --caps '{"appium:appPackage":"com.example.app","appium:appActivity":".MainActivity"}'

testsigma devices list --local shows physical devices, booted iOS simulators, and running Android emulators; --device takes any of them. Android emulators run exactly like physical devices. iOS simulators are not supported end-to-end yet — WebDriverAgent for them comes from Testsigma and the CLI is not wired to fetch it.

Install the app under test yourself before the run; the CLI never pushes it. A simulator needs a simulator build (.app), not the device .ipa.

A physical iOS device needs WebDriverAgent installed from a build resigned against a provisioning profile. Assign one to the device under Settings → Provisioning Profiles (/ui/settings/provisioning_profiles) before using the CLI.

--cloud is reserved: cloud execution is not implemented yet, and the flag says so rather than quietly running on this machine.

Push to Testsigma

testsigma test push --sprint <sprint> --module <module>

--issue, --priority, --test-type and --unmapped are also available; see testsigma test push --help.

Browse your workspace

testsigma projects list
testsigma sprints list
testsigma sprints issues
testsigma modules list
testsigma test-types list

testsigma devices list  --local
testsigma browsers list --local

Configuration

testsigma config show
testsigma --version

Runs go to the local agent by default. Point them at the cloud, or override either URL:

testsigma config set execution.target cloud
testsigma config set execution.localUrl http://127.0.0.1:8686
testsigma config unset execution.localUrl   # back to the built-in default

execution.target (local | cloud) is the default for commands that reach Testsigma; test run ignores it and requires its own --local/--cloud. The URLs are overrides — left unset, each follows the installed build, and TESTSIGMA_CLI_QI_URL still wins over a stored execution.cloudUrl.

testsigma --help and testsigma <command> --help list every option. Add --json for machine-readable output, or --raw for the bare value — an id per line from a list, the results-file path from a run.

Credentials and config live in ~/.testsigma/cli-<env>/config.json, where <env> is the environment the build targets, so a production CLI never shares state with a staging one.

Documentation

testsigma.com/docs