We run unit tests as part of the build process using chromite's cros_run_unit_tests
. In a nutshell, this script uses the portage method of building and running unit tests using FEATURES="test"
. To run all the Chromium OS unit tests, you can run cros_run_unit_tests
. If you want to run just the unit tests for specific packages, you can use:
(chroot) $ cros_run_unit_tests \ --packages <space-delimited list of portage package names>
See cros_run_unit_tests --help
for more information.
As an example, let's say you just want to run the unit tests for the metrics package. To do so, you can run:
(chroot) $ cros_run_unit_tests --board ${BOARD} --packages "metrics"
For platform2 packages, see the platform2 testing section.
For other packages that use gtest
:
(chroot) $ GTEST_ARGS="--gtest_filter=FreeDiskSpaceTest.*" cros_run_unit_tests \ --board ${BOARD} --packages google-breakpad
For packages using platform2, see the metrics ebuild as a good example of adding your unit test. These steps include:
platform_pkg_test()
stanza with appropriate gtest
filters (see below).*_test.cc
test file (see example file).gtest
syntax and the usages from Google Test - Chromium's C++ test harness.See example CL for a good example of adding new unit tests. These steps include:
src_test()
stanza with appropriate gtest
filters (see below), and add test? ( dev-cpp/gtest:= )
toDEPEND
in your ebuild.*_test.cc
test file (see example file).gtest
syntax and the usages from Google Test - Chromium's C++ test harness.Regarding src_test()
stanza, it is fine to have them build in the src_compile()
stage as well. See also Portage documentation on src_test()
.
Platform2 supports running unittests via QEMU for non-native architectures (low level details can be found in this doc). The good news is that the process is the same as described above! Simply use cros_run_unit_tests
for your board and specify the packages you want to run.
Sometimes QEMU is not able to support your unittest due to using functionality not yet implemented. If you see errors like qemu: unknown syscall: xxx
, you will need to filter that test (see below), and you should file a bug so we can update QEMU.
Since QEMU only works when run inside the chroot, only ebuilds that use the platform.eclass
are supported currently.
Sometimes a test is flaky or requires special consideration before it'll work. In general it is not recommended to disable flaky/broken tests in ebuilds. Instead add DISABLED_
to the prefix of the test name in the source, hence eliminating to touch ebuilds at all. Look at this example CL. Otherwise, see below for disabling tests in ebuilds.
For packages using platform.eclass
use the existing gtest filtering logic by simply passing it as an argument to platform_test
:
platform_pkg_test() { local gtest_filter="" gtest_filter+="DiskManagerTest.*" platform_test "run" "${OUT}/some_testrunner" "0" "${gtest_filter}" }
For other packages, export the relevant gtest variables directly in src_test()
function.
For packages using platform.eclass
update the global knob in your ebuild:
PLATFORM_NATIVE_TEST="yes"
For other packages, write your src_test()
like so:
src_test() { if ! use x86 && ! use amd64; then ewarn "Skipping unittests for non-native arches" return fi ... existing test logic ... }
For platform2 users, unittests run as non-root by default. If a unittest really needs root access, they can do so. Here is an example CL showing how to. It is recommended to mark such tests with RunAsRoot
in their names.
By default, cros_run_unit_tests
will only use FEATURES="test"
on packages that:
virtual/target-os
(packages only installed in SDK are ignored).src_test()
function; i.e. ebuilds that:src_test()
, orplatform_pkg_test()
& inherit the platform
eclass, orcros-common.mk
eclass, orcros-go
eclass, ortast-bundle
eclass.