
Wd Test Format
- 35 installs
- 8.5k repo stars
- Updated August 5, 2026
- cloudflare/workerd
wd-test-format guides authoring workerd .wd-test integration configs.
About
The wd-test-format skill explains .wd-test files as Capn Proto workerd configs for JS/TS integration tests. Basic structure uses Workerd.Config services with embed modules, compatibilityFlags instead of compatibilityDate, and bindings for text, data, and service namespaces. Module types include esModule, json, wasm, and commonJsModule. Mandates loading reference/advanced-configs.md for Durable Objects, multi-service bindings, network access, and TypeScript tests. Use when writing or reviewing workerd integration test configs.
- Capn Proto wd-test schema and embed module patterns.
- compatibilityFlags instead of compatibilityDate in tests.
- Bindings section for env text and service wiring.
- Advanced configs reference for DO and multi-service tests.
- Module type table for esModule json wasm commonJs.
Wd Test Format by the numbers
- 35 all-time installs (skills.sh)
- Ranked #1,312 of 2,153 Testing & QA skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
wd-test-format capabilities & compatibility
- Capabilities
- wd test basic structure and module types
- Use cases
- testing
npx skills add https://github.com/cloudflare/workerd --skill wd-test-formatAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 35 |
|---|---|
| repo stars | ★ 8.5k |
| Last updated | August 5, 2026 |
| Repository | cloudflare/workerd ↗ |
How do I write a workerd .wd-test integration test?
Author workerd .wd-test Capn Proto integration test configurations.
Who is it for?
workerd contributors authoring integration tests.
Skip if: Skip for kj_test C++ unit tests only.
When should I use this skill?
Writing or reviewing .wd-test files in workerd.
What you get
Valid wd-test Capn Proto config with modules and bindings.
Files
.wd-test File Format
.wd-test files are Cap'n Proto configs that define test workers for workerd's test framework. They use the schema defined in src/workerd/server/workerd.capnp.
---
MANDATORY: Load Reference File When Relevant
This skill is split across multiple files for context efficiency. The core patterns below cover standard single-service tests. Advanced configuration patterns live in a reference file.
You MUST read the reference file before writing or reviewing test configs that involve its subject matter. Do not guess at advanced config syntax — the reference file contains the exact patterns and fields required. Skipping it WILL lead to incorrect configs that fail at runtime.
| File | MUST load when... |
|---|---|
reference/advanced-configs.md | Test involves Durable Objects, multiple services |
| communicating via service bindings, outbound network access, | |
| external services/sockets, or TypeScript source files |
When in doubt about whether the reference file is relevant, load it — the cost of reading is far less than the cost of a broken test config.
---
Basic Structure
using Workerd = import "/workerd/workerd.capnp";
const unitTests :Workerd.Config = (
services = [(
name = "my-test",
worker = (
modules = [(name = "worker", esModule = embed "my-test.js")],
compatibilityFlags = ["nodejs_compat_v2"],
),
)],
);Key rules:
- The const name (e.g.,
unitTests) must match what the test runner expects modulesusesembedto inline file contents at build time- The first module should be named
"worker"— this is the entry point compatibilityFlagscontrol which APIs are available. Use thecompat-date-attool to look up available flags and their enable dates.compatibilityDateshould not be used in wd-test; use specific flags instead
Module Types
modules = [
(name = "worker", esModule = embed "my-test.js"), # ES module (most common)
(name = "helper", esModule = embed "helper.js"), # Additional ES module
(name = "data.json", json = embed "test-data.json"), # JSON module
(name = "data.wasm", wasm = embed "module.wasm"), # WebAssembly module
(name = "legacy", commonJsModule = embed "legacy.js"), # CommonJS module
],Bindings
Bindings make services, data, and namespaces available to the worker via env:
bindings = [
# Text binding — env.MY_TEXT is a string
(name = "MY_TEXT", text = "hello world"),
# Text from file
(name = "CERT", text = embed "fixtures/cert.pem"),
# Data binding — env.MY_DATA is an ArrayBuffer
(name = "MY_DATA", data = "base64encodeddata"),
# JSON binding — env.CONFIG is a parsed object
(name = "CONFIG", json = "{ \"key\": \"value\" }"),
# Service binding — env.OTHER_SERVICE is a fetch-able service
(name = "OTHER_SERVICE", service = "other-service-name"),
# Service binding with entrypoint
(name = "MY_RPC", service = (name = "my-service", entrypoint = "MyClass")),
# KV namespace — env.KV is a KV namespace
(name = "KV", kvNamespace = "kv-namespace-id"),
# Durable Object namespace — env.MY_DO is a DO namespace
(name = "MY_DO", durableObjectNamespace = "MyDurableObject"),
],Test JavaScript Structure
Test files export named objects with a test() method:
// Each export becomes a separate test case
export const basicTest = {
test() {
// Synchronous test
assert.strictEqual(1 + 1, 2);
},
};
export const asyncTest = {
async test(ctrl, env) {
// ctrl is the test controller
// env contains bindings from the .wd-test config
const resp = await env.OTHER_SERVICE.fetch('http://example.com/');
assert.strictEqual(resp.status, 200);
},
};BUILD.bazel Integration
wd_test(
src = "my-test.wd-test",
args = ["--experimental"], # Required for experimental features
data = ["my-test.js"], # Test JS/TS files
)Additional data entries for fixture files:
wd_test(
src = "crypto-test.wd-test",
args = ["--experimental"],
data = [
"crypto-test.js",
"fixtures/cert.pem",
"fixtures/key.pem",
],
)Test Variants
Every wd_test() automatically generates three variants:
| Target suffix | Compat date | Description |
|---|---|---|
@ | 2000-01-01 | Default, tests with oldest compat date |
@all-compat-flags | 2999-12-31 | Tests with all flags enabled |
@all-autogates | 2000-01-01 | Tests with all autogates enabled |
Run specific variants:
just stream-test //src/workerd/api/tests:my-test@
just stream-test //src/workerd/api/tests:my-test@all-compat-flagsScaffolding
Use just new-test to scaffold a new test:
just new-test //src/workerd/api/tests:my-testThis creates the .wd-test file, .js test file, and appends the wd_test() rule to BUILD.bazel.
Advanced .wd-test Config Patterns
Patterns for Durable Objects, multi-service tests, network access, external services, and TypeScript tests.
---
Durable Objects
To test Durable Objects, define the namespace and storage:
const unitTests :Workerd.Config = (
services = [
( name = "do-test",
worker = (
modules = [(name = "worker", esModule = embed "do-test.js")],
compatibilityDate = "2024-01-01",
durableObjectNamespaces = [
(className = "MyDurableObject", uniqueKey = "210bd0cbd803ef7883a1ee9d86cce06e"),
],
durableObjectStorage = (localDisk = "TEST_TMPDIR"),
bindings = [
(name = "MY_DO", durableObjectNamespace = "MyDurableObject"),
],
),
),
# Disk service for DO storage
(name = "TEST_TMPDIR", disk = (writable = true)),
],
);The uniqueKey is a hex string that uniquely identifies the namespace. Use any 32-char hex string for tests.
For in-memory storage (no persistence between requests), use:
durableObjectStorage = (inMemory = void),Multi-Service Configs
Tests can define multiple services that communicate via service bindings:
const unitTests :Workerd.Config = (
services = [
( name = "main-test",
worker = (
modules = [(name = "worker", esModule = embed "main-test.js")],
compatibilityDate = "2024-01-01",
bindings = [
(name = "BACKEND", service = "backend"),
],
),
),
( name = "backend",
worker = (
modules = [(name = "worker", esModule = embed "backend.js")],
compatibilityDate = "2024-01-01",
),
),
],
);For large configs, factor out worker definitions as named constants:
const unitTests :Workerd.Config = (
services = [
(name = "main", worker = .mainWorker),
(name = "helper", worker = .helperWorker),
],
);
const mainWorker :Workerd.Worker = (
modules = [(name = "worker", esModule = embed "main.js")],
compatibilityDate = "2024-01-01",
bindings = [(name = "HELPER", service = "helper")],
);
const helperWorker :Workerd.Worker = (
modules = [(name = "worker", esModule = embed "helper.js")],
compatibilityDate = "2024-01-01",
);Network Access
For tests that need outbound network access:
( name = "internet",
network = (
allow = ["private"],
tlsOptions = (
trustedCertificates = [
embed "test-cert.pem",
],
),
)
),allow can be ["private"] (loopback/LAN) or ["public"] (internet). Most tests use "private".
External Services
For testing RPC over sockets or external service communication:
( name = "my-external",
external = (
address = "loopback:my-external",
http = (capnpConnectHost = "cappy")
)
),TypeScript Tests
TypeScript test files use a .ts-wd-test extension for the config, but the embedded module is the compiled .js output:
Config file (my-test.ts-wd-test):
using Workerd = import "/workerd/workerd.capnp";
const unitTests :Workerd.Config = (
services = [(
name = "my-test",
worker = (
modules = [(name = "worker", esModule = embed "my-test.js")],
compatibilityDate = "2024-01-01",
),
)],
);BUILD.bazel references the .ts source:
wd_test(
src = "my-test.ts-wd-test",
args = ["--experimental"],
data = ["my-test.ts"],
)The build system compiles the .ts to .js automatically.
Related skills
FAQ
What does wd-test-format do?
wd-test-format guides authoring workerd .wd-test integration configs.
When should I use wd-test-format?
Writing or reviewing .wd-test files in workerd.
Is this skill safe to install?
Review the Security Audits panel on this page before installing in production.