用途：介绍在 workerd 项目中查找、构建和运行测试的方法，覆盖 wd-test、kj_test 目标命名、bazel query 模式与常用标志，并说明父项目集成测试的通用原则。
测试类型：JS/TS 集成测试使用 .wd-test 扩展名与 wd_test() BUILD 宏，无目标后缀，目标名等于规则名；C++ 单元测试使用 *-test.c++ 文件与 kj_test() 宏，也无目标后缀。
查找目标：可用 bazel query 定位测试目标，例如按目录查询 kind("test", //src/workerd/api/tests:)，或按名称匹配 kind("._test", //src/workerd/...) 后 grep。查找依赖某源文件的测试可用 rdeps，如 rdeps(//src/..., //src/workerd/io:trace-stream, 1)。
运行方式：调试时推荐流式输出 bazel test //src/workerd/api/tests:url-test --test_output=streamed；需忽略缓存时加 --nocache_test_results；运行 kj_test 内特定用例用 --test_arg='-f' --test_arg='test case name'。常用标志包括 --test_output=streamed、--nocache_test_results、--test_timeout=120。
父项目集成测试：若 workerd 作为父项目的子模块，父项目可能有自己的集成测试框架与约定，需加载 parent-project-skills 技能了解。通用原则：部分测试宏会通过变体后缀（如 @、@all-autogates、@force-sharding）从单个源文件生成多个目标，若 bazel 提示源文件无构建或无测试目标，通常需要补充后缀，可用 bazel query 'kind("test", //path:*)' 发现实际可运行目标名。缓存结果会掩盖改动，修改测试或源码后重跑务必使用 --nocache_test_results，否则会返回带陈旧日志的缓存结果。测试通过后应检查输出中是否有功能实际运行的证据（脚本名、进程类型、子请求、RPC 调用），无证据的通过测试不能算有效测试。
限制：资料未提供 workerd 测试之外的安装或环境配置细节，相关收费、平台与效果信息暂未提供。