find-and-run-tests

Finding and Running Tests

workerd Tests

Test types

Finding targets

# Find test targets in a directory
bazel query 'kind("test", //src/workerd/api/tests:*)' --output label
 
# Find test targets matching a name
bazel query 'kind(".*_test", //src/workerd/...)' --output label 2>/dev/null | grep -i '<name>'
 
# Find tests that depend on a source file

Running

Common flags

Parent Project Integration Tests

If workerd is used as a submodule in a parent project, that project may have its own integration test framework with different conventions. Load the parent-project-skills skill to discover those conventions.

General principles that apply to any integration test framework

Target naming with variant suffixes. Some test macros generate multiple targets from a single source file by appending variant suffixes (e.g., @, @all-autogates, @force-sharding). If bazel says "is a source file, nothing will be built" or "No test targets were found", you likely need a suffix. Use bazel query 'kind("test", //path:*)' to discover the actual runnable target names.

Cached results hide changes. Always use --nocache_test_results when re-running after modifying test files or source code. Without it, bazel returns stale cached results with stale logs.

Verify the feature actually ran. After a test passes, search the test output for feature-specific evidence (script names, process types, subrequests, RPC calls). A passing test with no evidence the feature ran is not a valid test — see the test-driven-investigation skill.

Debugging test failures

1. Always use --nocache_test_results when re-running after changes.
2. Check test logs at the path shown in bazel output: bazel-out/.../testlogs/.../test.log
3. Search logs for feature-specific keywords to verify the feature actually ran.
4. Subrequest mismatches (in frameworks that verify subrequests) typically show the actual vs expected request details — compare control headers carefully.