If you want to run web tests, build the target
blink_tests; this includes all the other binaries required to run the tests.
You can run web tests using
python third_party/blink/tools/run_web_tests.py storage/indexeddb
To see a complete list of arguments supported, run with
PATHso that you can run it from anywhere without the full path.
In some cases (e.g. for debugging), you can run web tests directly with Content Shell executable, with the
out/Default/content_shell --run-web-tests <url>|<full_test_source_path>|<relative_test_path>
<relative_test_path> is relative to the web_tests directory, regardless of the current directory.
out/Default/content_shell --run-web-tests fast/forms/001.html
out/Default/content_shell --run-web-tests \ /home/user/chrome/src/third_party/blink/web_tests/fast/forms/001.html
out/Default/content_shell --run-web-tests ~/test/temp-test.html
By default, it dumps the text result only (as the dump of pixels and audio binary data is not human readable). This can meet the requirement of most debugging requirements.
In rare cases, to run
content_shell in the exact same way as
run_web_tests.py runs it, you need to run it in the protocol mode.
On the Mac, use
Content Shell.app, not
out/Default/Content\ Shell.app/Contents/MacOS/Content\ Shell ...
On Windows, use
HTTP tests reside under web_tests/http/tests. You need to start a web server first:
Then run the test with a localhost URL:
out/Default/content_shell --run-web-tests http://localhost:8000/<test>
Similar to HTTP tests, many WPT (a.k.a. web-platform-tests under web_tests/external/wpt directory) tests require some setup before running in Content Shell:
Then run the test:
out/Default/content_shell --run-web-tests http://localhost:8001/<test>
See the blink-dev discussion for more details.
You can run the shell directly as a simple browser:
This allows you see how your changes look in Chromium. You can inspect the page by right clicking and selecting ‘Inspect Element’.
You can also use
http://localhost:9222 from another browser to inspect the page. This is useful when you don‘t want DevTools to run in the same Content Shell, e.g. when you are logging a lot and don’t want the log from DevTools or when DevTools is unstable in the current revision due to some bugs.
The command line switch
--single-process is useful for starting content_shell in gdb. In most cases,
--single-process is good for debugging except when you want to debug the multiple process behavior or when we have some bug breaking
--single-process in particular cases.
See Run Web Tests Directly with Content Shell. In most cases you don't need
content_shell is in single process mode when running most web tests.
See DevTools frontend for the commands that are useful for debugging devtools web tests.
In rare cases, you need to debug Content Shell in multiple process mode. You can ask Content Shell to wait for you to attach a debugger once it spawns a renderer process by adding the
out/Default/content_shell --renderer-startup-dialog --no-sandbox
Debugging workers and other subprocesses is simpler with
--wait-for-debugger-children, which can have one of two values:
To avoid writing (and maintaining!) yet another test controller, it is desirable to reuse an existing test controller. A possible solution would be to change DRT‘s test controller to not depend on DRT’s implementation of the Blink objects, but rather on the Blink interfaces. In addition, we would need to extract an interface from the test shell object that can be implemented by content shell. This would allow for directly using DRT's test controller in content shell.