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의 다른 스킬

workerd-api-review
cloudflare
workerd 코드 리뷰를 위한 성능 최적화, API 설계 및 호환성, 보안 취약점, 표준 사양 준수. tcmalloc 인식…
official
workerd-safety-review
cloudflare
메모리 안전성, 스레드 안전성, 동시성, 그리고 workerd 코드 리뷰를 위한 중요 탐지 패턴. V8/KJ 경계 위험 요소, 수명 관리 등을 다룹니다.
official
module-registry
cloudflare
workerd에서 모듈 레지스트리를 작업할 때 로드 — 모듈 해석, 컴파일, 평가, 등록을 읽기, 수정, 디버깅, 검토하는 경우…
official
reproduce
cloudflare
cloudflare/agents GitHub 이슈를 재현하기 위해 최소한의 Agents/Worker 프로젝트를 스캐폴딩하고 임시 Cloudflare 계정에 배포한 후 보고합니다…
official
local-explorer
cloudflare
로컬 탐색기 또는 로컬 API에 제품/리소스를 추가하는 방법. 새로운 로컬 API나 UI 라우트를 구현할 때 사용합니다.
official
commit-categories
cloudflare
커밋을 체인지로그와 "새로운 기능" 요약으로 분류하는 규칙입니다. 체인지로그 또는 whats-new 명령에서 커밋을 분류하기 전에 반드시 로드되어야 합니다. 제공하는 기능:
official
architecture
cloudflare
코드베이스를 처음 탐색할 때, 새 클라이언트 메서드를 추가할 때, 새 컨테이너 핸들러/서비스를 추가할 때, 또는 요청 흐름을 이해할 때 사용합니다.
official
changesets
cloudflare
변경셋을 생성하거나, 릴리즈를 준비하거나, 버전을 올릴 때 사용합니다. 참조할 패키지, 사용자 대상 변경셋 설명 작성 방법 등을 다룹니다.
official