Menu
Executes and interprets V8 tests. Use when running unittests, cctest, or mjsunit, or when debugging test failures. Do not use for building.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Managing and querying Perfetto traces using the trace_processor MCP server.
Documentation for conditional testing in V8 using gm.py.
Guides the initial analysis and impact assessment of a V8 security report, strictly excluding implementation or fixing.
Manages git task isolation and environment setup in V8. Use at the start of any new task or bug fix. Do not use for general C++ editing.
Workflow for issue-based debugging in V8. Use when tasked with debugging a specific issue, usually associated with a Buganizer ID or a specific reproduction script. Do not use for performance regressions.
Workflow for general debugging tasks without the overhead of issue tracking. Use when investigating crashes, hangs, or unexpected behavior where no specific issue ID is provided. Do not use when issue ID is provided.
| name | v8-testing |
| description | Executes and interprets V8 tests. Use when running unittests, cctest, or mjsunit, or when debugging test failures. Do not use for building. |
Use this skill to understand how to run tests in V8 and how to handle failures. This specializes the general commands for testing.
The primary script for running tests is tools/run-tests.py. You specify the
build output directory and the tests you want to run.
# Run all standard tests for the x64.optdebug build
tools/run-tests.py --progress dots --exit-after-n-failures=5 --outdir=out/x64.optdebug
# Run a specific test suite (e.g., cctest)
tools/run-tests.py --progress dots --exit-after-n-failures=5 --outdir=out/x64.optdebug cctest
# Run a specific test file
tools/run-tests.py --progress dots --exit-after-n-failures=5 --outdir=out/x64.optdebug cctest/test-heap
# Manual execution with d8
# Note: mjsunit tests always require test/mjsunit/mjsunit.js.
# tools/run-tests.py prepends this automatically for all tests in mjsunit,
# so you don't need to load it explicitly in the test file.
# For manual d8 execution, you must include it first.
# You can also run tools/run-tests.py with -v to see the full command line used by the runner.
out/x64.optdebug/d8 test/mjsunit/mjsunit.js test/mjsunit/my-test.js
Note: Always pass --progress dots so that there is minimal progress
reporting, to avoid cluttering the output.
To maximize efficiency, use different build configurations based on the task:
x64.debug: Use this for deep debugging of a single test case (e.g., with
GDB). It is slow but provides full debug information and assertions.x64.optdebug: Use this for running the entire test suite. It strikes a
balance between performance and debuggability, allowing for faster full-suite
checks while still preserving assertions.x64.release: Use this for quick checks to verify that a fix works in a
release build or to run benchmarks. It is the fastest but provides the least
debug information.If there are any failing tests, they will be reported along their stderr and a command to reproduce them e.g.
=== mjsunit/maglev/regress-429656023 ===
--- stderr ---
#
# Fatal error in ../../src/heap/local-factory.h, line 41
# unreachable code
#
...stack trace...
Received signal 6
Command: out/x64.optdebug/d8 --test test/mjsunit/mjsunit.js test/mjsunit/maglev/regress-429656023.js --random-seed=-190258694 --nohard-abort --verify-heap --allow-natives-syntax
You can retry the test either by running the test name with
tools/run-tests.py, e.g.
tools/run-tests.py --progress dots --outdir=out/x64.optdebug mjsunit/maglev/regress-429656023,
or by running the command directly. When running the command directly, you can
add additional flags to help debug the issue, and you can try running a
different build (e.g. running a debug build if a release build fails).