breadcrumbs: Testing and infrastructure > page_name: running-tests title: Running tests locally
src\chrome\Debug
, e.g. src\chrome\Debug\base_unittests.exe
cd
src/
Run the test of interest, e.g. ./out/Debug/base_unittests
Many unit tests create a chromium UI, which means they need the ability to create a visible window. To run these tests remotely in a terminal, or to keep them from opening windows in your current desktop session, you can run tests inside Xvfb. See “Running in headless mode” below.
You can't run browser tests or unit tests on actual Chrome OS devices or from within the cros chrome-sdk shell; instead, run them on a Linux system using a build directory with target_os=“chromeos”.
The above test executables are built with gtest, so they accept command line arguments to filter which sub-tests to run. For instance, base_unittests --gtest_filter=FileUtilTest.*
Tests that create a visible window do not draw anything into the window by default, in order to run the test faster (with exception of tests that verify pixel output). To force tests to draw visible pixels for debugging, you can use the --enable-pixel-output-in-tests command-line flag. This can be used for both unit tests and browser tests.
Blink has a large suite of tests that typically verify a page is laid out properly. We use them to verify much of the code that runs within a Chromium renderer. To run these tests, build the blink_tests target and then run third_party/blink/tools/run_web_tests.py --debug .
More information about running web tests or fixing web tests can be found on the Web Tests page.
Most top-level directories of src/ have a unit test build target, such as content_unittests
for content/
, cc_unittests
for cc/
, and components_unittests
for components/
There is also the fallback unit_tests
target for unit tests built on top of the full chrome stack.
Unit tests verify some part of the chromium code base in an isolated test environment, and are usually found in files with a _unittest.cc
suffix. Browser tests run a full browser, and then execute a test inside the browser instance, and are usually found in files with a _browsertest.cc
suffix. There is more information on browser tests here. To add a new test, you will generally find a similar test and clone it. If you can, strongly prefer writing a unit test over a browser test as they are generally faster and more reliable.
Before running the tests, make sure to run crash_service.exe
. We use this program to intercept crashes in chromium and write a crash dump in the Crash Reports folder under the User Data directory of your chromium profile.
If you also want crash_service.exe
to intercept crashes for your normal Google Chrome or Chromium build, add the flag --noerrdialogs
.
You can also use the flag --enable-dcheck
to get assertion errors in release mode.
--ozone-platform
or xvfbWhen ssh-ed in to a machine, you don‘t have a display connected, which means that you normally can’t run tests. Some tests don't need to draw to the screen, and for them you can simply add --ozone-platform=headless
to your command line. For the others, you can run tests in headless mode with xvfb (X Virtual Frame Buffer). There are multiple ways to run tests with xvfb!
Example with unittests and testing/xvfb.py (note: you will need to install xcompmgr, although this is done as part of install-build-deps.py)
testing/xvfb.py out/Default/component_unittests
Example with browser tests and running Xvfb and setting the DISPLAY env variable.
Xvfb.py :100 -screen 0 1600x1200x24 & DISPLAY=localhost:100 out/Default/browser_tests
Third example, with xvfb-run:
xvfb-run -s “-screen 0 1024x768x24” out/Default/content_unittests
Browser tests on gLinux start up extremely slowly due to idiosyncratic NSS configurations. If you need to regularly run browser tests on gLinux, consider using the run_with_dummy_home.py helper script:
testing/run_with_dummy_home.py testing/xvfb.py out/Default/browser_tests
This can speed tests up by 5x or more.