wd-test-format

작성자: cloudflare

workerd에서 .wd-test 파일을 작성하기 위한 상세 가이드로, 바인딩, Durable Objects, 다중 서비스 구성, TypeScript 테스트 및 네트워크 액세스 예제를 포함합니다.

npx skills add https://github.com/cloudflare/workerd --skill wd-test-format

.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.

FileMUST load when...
reference/advanced-configs.mdTest 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
  • modules uses embed to inline file contents at build time
  • The first module should be named "worker" — this is the entry point
  • compatibilityFlags control which APIs are available. Use the compat-date-at tool to look up available flags and their enable dates.
  • compatibilityDate should 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 suffixCompat dateDescription
@2000-01-01Default, tests with oldest compat date
@all-compat-flags2999-12-31Tests with all flags enabled
@all-autogates2000-01-01Tests 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-flags

Scaffolding

Use just new-test to scaffold a new test:

just new-test //src/workerd/api/tests:my-test

This creates the .wd-test file, .js test file, and appends the wd_test() rule to BUILD.bazel.

cloudflare의 다른 스킬

dependabot-review
cloudflare
Dependabot PR을 분석하여 각 업데이트된 패키지에서 실제로 변경된 사항과 해당 변경 사항이 이 저장소에 영향을 미치는지 확인합니다. 변경된 API/메서드 등을 보고합니다.
module-registry
cloudflare
workerd에서 모듈 레지스트리를 작업할 때 로드 — 모듈 해석, 컴파일, 평가, 등록을 읽기, 수정, 디버깅, 검토하는 경우…
reproduce
cloudflare
cloudflare/agents GitHub 이슈를 재현하기 위해 최소한의 Agents/Worker 프로젝트를 스캐폴딩하고 임시 Cloudflare 계정에 배포한 후 보고합니다…
local-explorer
cloudflare
로컬 탐색기 또는 로컬 API에 제품/리소스를 추가하는 방법. 새로운 로컬 API나 UI 라우트를 구현할 때 사용합니다.
open-pr
cloudflare
클라우드플레어/에이전트 GitHub 이슈와 재현 결과를 바탕으로 수정 PR을 한 번에 생성합니다 — 브랜치 생성, 변경, 테스트, 푸시, 그리고 이슈에 연결된 PR 열기까지 수행합니다.
write-endpoints
cloudflare
chanfana를 사용한 OpenAPI 엔드포인트 구축을 위한 종합 가이드 - 스키마 정의, 요청 검증, CRUD 작업, D1 데이터베이스 통합 등
agents-sdk
cloudflare
Cloudflare Workers에서 Agents SDK를 사용하여 AI 에이전트를 구축하세요. 상태 저장 에이전트, 지속 가능한 워크플로우, 실시간 WebSocket 앱, 예약된 작업 등을 생성할 때 로드하세요.
changelog
cloudflare
Cloudflare 문서 사이트의 제품 변경 로그 항목을 생성, 업데이트 및 검토합니다. 변경 로그 MDX 파일을 생성하거나 기존 파일을 편집할 때 로드합니다.