Tests can be executed within a ChromeOS chroot using the
tast run <target> <test-pattern> <test-pattern> ...
To run private tests (e.g.
crosint test bundle), use
The first positional argument supplied to the
run subcommand specifies the “target”, i.e. the device where the test will be run, also known as the device-under-test or DUT. In the case of local tests, the test code will run directly on the DUT. For remote tests, the test code will run on the host machine but connect to the DUT. Expressions like
10.0.0.2 are supported. The root user is used by default, as tests frequently require root access to the DUT.
By default, the standard
testing_rsa key from
chromite/ssh_keys will be used to establish an SSH connection with the device. The
keyfile flag can be supplied to specify a different private key:
tast run -keyfile=$HOME/.ssh/id_rsa ...
Any additional positional arguments describe which tests should be executed:
(("dep:chrome" || "dep:android") && !informational)matches all tests with a
dep:androidattribute but not an
informationalattribute. Attributes that don't consist of a letter or underscore followed by letters, digits, and underscores must be double-quoted. ‘*’ characters in quoted strings are interpreted as wildcards. See chromiumos/tast/internal/expr for details about expression syntax.
ui.*matches all tests with names prefixed by
ui.. Multiple patterns can be supplied: passing
example.Failselects those two tests.
See the Test Attributes document for more information about attributes.
Tests may be skipped if they list software dependencies that aren‘t provided by the DUT. This behavior can be controlled via the
-build flag is true (the default),
tast run rebuilds the
cros test bundle and pushes it to the DUT as
/usr/local/share/tast/bundles_pushed/cros. This permits faster compilation and deployment when writing new tests than the normal
cros deploy cycle can provide.
The name of the bundle to build, push, and run can be specified via the
-buildbundle flag. If the bundle‘s source code is outside of the tast-tests repository, you will need to specify the repository’s path using the
To rebuild a test bundle, the
tast command needs its dependencies' source code to be available. This code is automatically checked out to
/usr/lib/gopath when building packages for the host system, as described in the [Go in Chromium OS] document. The
tast command will automatically inform you when the bundle's dependencies need to be manually emerged.
To skip rebuilding a bundle and instead run all builtin bundles within the
/usr/local/share/tast/bundles directory on the DUT (for local tests) and
/usr/share/tast/bundles on the host system (for remote tests), pass
-build=false. The default builtin
cros local bundle should be present on all
test system images (non-
test system images are not supposed by Tast).
Some tests use servo, a physical device that connects to both the host machine and the DUT. These tests all specify
servo as a runtime variable, so they must be run with that variable specifying the servo host and servo port:
tast run -var=servo=<servo-host>:<servo-port> <target> <test-pattern>
In order for a test to interact with the servo, the servo host must be running an instance of
servod (servo daemon) on the appropriate port. When Tast is run through the Tauto wrapper via
test_that, Tauto takes care of initiating and closing
servod. However, when Tast is run through
tast run, it does not initiate
servod; the user must initiate
servod from the servo host:
ssh <servo-host> servod --board=<board> --model=<model> --port=<servo-port> --serialname=<servo-serial>
In automated testing in the ChromeOS lab, Tast tests can reach a working Servo device via
servo runtime variable if they are scheduled with Autotest control files declaring a Servo dependency. Control files for mainline tests declare it, but other control files may not. See crrev.com/c/2790771 for an example to add a dependency declaration.
As each test runs, its output is streamed to the
tast executable. Overall information about the current state of the test run is logged to stdout by default. The top-level (i.e.
tast -verbose run ...)
-verbose flag can be supplied to log additional information to the console, including all messages written by tests.
By default, test results are written to a subdirectory under
/tmp/tast/results, but an alternate directory can be supplied via the
-resultsdir flag. If the default directory is used, a symlink will also be created to it at
Various files and directories are created within the results directory:
crashes/- Breakpad minidump files with information about crashes that occured during testing.
full.txt- All output from the run, including messages logged by individual tests.
results.json- Machine-parseable test results, supplied as a JSON-marshaled array of run.TestResult structs.
run_error.txt- Error message describing the reason why the run was aborted (e.g. SSH connection to DUT was lost). Only written when a global error occurs.
streamed_results.jsonl- Streamed machine-parseable test results, supplied as a JSONL array of run.TestResult structs. Provides partial results if the
tastprocess is interrupted before
system_logs/- Diff of
/var/logon the DUT before and after testing.
unified/- Unified log collected from system logs.
unified.log- Human-readable system log messages.
unified.export.gz- gzip-compressed logs with full metadata from croslog's export mode which is similler to
journalctl -o export.
tests/<test-name>/- Per-test subdirectories, containing test logs and other output files.
timing.json- Machine-parsable JSON-marshaled timing information about the test run produced by the timing package.
Tast resets the device owner of the DUT before test run, and after the test run, the device owner remains to be testuser. To reset that, run the following on the DUT:
stop ui rm -rf /var/lib/devicesettings '/home/chronos/Local State' start ui
In a window outside the chroot do,
gcert # Once a day ssh -L <port>:localhost:22 root@<dut> # One session for each DUT
Any port is fine as long as it is not used by other applications. Leave the ssh session on.
In another window inside chroot:
tast run localhost:<port> <test>