Tests can be executed within a Chrome OS chroot using the tast
executable's run
command:
tast run <target> <test-pattern> <test-pattern> ...
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 root@10.0.0.1:22
, root@localhost
, and 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:
(chrome && !(flaky || disabled))
matches all tests with a chrome
attribute but not a flaky
or disabled
attribute.ui.*
matches all tests with names prefixed by ui.
. Multiple patterns can be supplied: passing example.Pass
and example.Fail
selects those two tests.It's invalid to mix attribute expressions and wildcard patterns.
The type
flag accepts a local
or remote
parameter to specify which type of test should be run. local
is the default, and remote
must be specified when running remote tests. A command similar to the following runs a remote test:
tast run -type=remote <target> power.Reboot
By default, tast run
rebuilds the binary containing the tests and (in the case of local tests) pushes it to the DUT as /usr/local/bin/local_tests_pushed
. This permits faster compilation and deployment when writing new tests than the normal emerge
/cros deploy
cycle can provide.
To rebuild test binaries, the tast
command needs their 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 tests' dependencies need to be manually emerged.
To skip this step and instead run a builtin test binary at /usr/local/bin/local_tests
, pass -build=false
. Builtin binaries will only be present if the chromeos-base/tast-local-tests
package was emerged to the DUT or chromeos-base/tast-remote-tests
was built for the host. The former happens automatically when a test image is built.
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 run
command's -resultsdir
flag. If the default directory is used, a symlink will also be created to it at /tmp/tast/results/latest
.
Various files are created within the results directory:
full.txt
- All output from the run, including messages logged by individual tests.results.json
- Machine-parseable test results.system_logs
- Diff of /var/log
on the DUT before and after testing (local tests only).tests
- Contains per-test subdirectories, each of which has messages logged by the test and any output files that it created.timing.json
- Machine-parsable timing information about the test run.If you need to run one or more local tests manually on a DUT (e.g. because you don't have a Chrome OS chroot containing the tast
executable), the local_tests
executable can be started directly on the DUT:
local_tests ui.ChromeSanity