본문으로 건너뛰기
cccskills
무료GitHub에 공개

cloudflare-workers-miniflare

Use when Cloudflare Workers code needs tests locally: Miniflare 3 (workerd-backed), wrangler dev, emulated KV, Durable Objects, R2 and D1 bindings, and in-process tests with Vitest and @cloudflare/vitest-pool-workers.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

testland/qa스타 13(GitHub 13 + cccskills 0)
연동 도구Cloudflare

실행 점수 미검증

설치 방법 보기

포함된 파일(2)

  • SKILL.md6.5 KB
  • .tessl-plugin/plugin.json361 B

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

cloudflare-workers-miniflare

Overview

Miniflare 3 is the official Workers simulator. Per developers.cloudflare.com/workers, Miniflare 3 is built on top of workerd - the same runtime that serves production Workers traffic. This means local-mode behaviour matches prod with very high fidelity.

Three integration patterns:

  1. wrangler dev (CLI; live-reload during dev).
  2. Programmatic Miniflare (getMiniflare(); for integration tests).
  3. @cloudflare/vitest-pool-workers (Vitest + in-process Workers; the recommended unit-test path).

When to use

  • Unit / integration tests for Cloudflare Workers code.
  • Tests for KV / Durable Objects / R2 / D1 bindings.
  • Local-development of Workers without deploying.

Authoring

Install

npm install --save-dev wrangler miniflare @cloudflare/vitest-pool-workers vitest

wrangler dev (CLI)

wrangler dev --local        # workerd locally; no remote calls
wrangler dev                # default = local-mode in Wrangler 3+

Now curl http://localhost:8787 hits the local Worker.

Programmatic Miniflare

Per miniflare.dev:

import { Miniflare } from 'miniflare';

const mf = new Miniflare({
  scriptPath: './src/worker.js',
  modules: true,
  kvNamespaces: ['MY_KV'],
  d1Databases: ['DB'],
  r2Buckets: ['MY_BUCKET'],
  durableObjects: {
    COUNTER: 'Counter',
  },
});

const res = await mf.dispatchFetch('https://example.com/');
expect(res.status).toBe(200);
expect(await res.text()).toBe('Hello');

await mf.dispose();

@cloudflare/vitest-pool-workers (recommended for unit tests)

Per developers.cloudflare.com/workers/testing/vitest-integration:

// vitest.config.ts
import { defineWorkersConfig } from '@cloudflare/vitest-pool-workers/config';

export default defineWorkersConfig({
  test: {
    poolOptions: {
      workers: {
        wrangler: { configPath: './wrangler.toml' },
      },
    },
  },
});

// src/worker.test.ts
import { env, SELF } from 'cloudflare:test';
import { expect, test } from 'vitest';

test('responds with hello', async () => {
  const response = await SELF.fetch('https://example.com/');
  expect(await response.text()).toBe('Hello');
});

test('writes to KV', async () => {
  await env.MY_KV.put('key', 'value');
  expect(await env.MY_KV.get('key')).toBe('value');
});

This is the lowest-overhead test path - runs inside workerd.

Durable Objects testing

import { env } from 'cloudflare:test';

test('counter increments', async () => {
  const id = env.COUNTER.idFromName('test');
  const stub = env.COUNTER.get(id);
  const r1 = await stub.fetch('https://example.com/increment');
  expect(await r1.text()).toBe('1');
  const r2 = await stub.fetch('https://example.com/increment');
  expect(await r2.text()).toBe('2');
});

Per Cloudflare docs, the vitest-pool-workers env exposes the Durable Object namespace exactly as in production.

D1 testing

import { env } from 'cloudflare:test';

test('d1 query', async () => {
  await env.DB.exec('CREATE TABLE IF NOT EXISTS users (id INT, name TEXT)');
  await env.DB.prepare('INSERT INTO users VALUES (?, ?)').bind(1, 'alice').run();
  const { results } = await env.DB.prepare('SELECT * FROM users').all();
  expect(results).toEqual([{ id: 1, name: 'alice' }]);
});

Running

npx vitest run                # @cloudflare/vitest-pool-workers
wrangler dev                  # CLI dev

CI integration

jobs:
  workers-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - run: npm ci
      - run: npx vitest run

No CF account/API key needed - vitest-pool-workers runs locally via workerd.

Anti-patterns

Anti-patternWhy it failsFix
Test against deployed WorkerSlow; flaky; rate-limitedUse vitest-pool-workers
Mock the fetch APILoses Workers' standard-Web-Platform shapeUse real Worker isolation
Skip Durable Object testsFan-out + consistency bugs hideTest DO classes directly
KV getWithMetadata not tested for stale-read behaviorKV is eventually consistentTest the consistency requirements
Local-mode time differs from prodCron / scheduled triggers won't fireTest via deployed Worker + Cloudflare Cron Trigger
Hardcoded API key in workerExposed in source map / fetchUse Workers Secrets (wrangler secret)
No assertion on response headersCache-Control / CORS bugsInspect response.headers
Cold-start tests against local WorkerLocal cold start ~0ms; not representativePer serverless-integration-test-builder (its cold-start budget reference), test cold-start budget on deployed Worker

Limitations

  • Workerd local-mode mirrors prod with ~95% fidelity. Edge- cases around network egress, KV durability, R2 ranges may differ. Test against staging for high-fidelity.
  • No production analytics in local-mode. Workers Analytics Engine writes are no-ops locally.
  • Bindings to remote services (e.g., remote KV from a different account) need explicit remote: true config in Wrangler 3.
  • Cron Triggers don't fire locally. Schedule events need manual dispatchFetch('https://example.com/__scheduled').
  • WebSocket Hibernation (Durable Objects) has subtleties in local mode; verify against deployed.

References

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Use when a project has accessibility debt and a zero-violations gate would block every PR. Builds a CI ratchet that fails only on new WCAG violations a PR introduces, with pre-existing ones baselined per rule and page, from axe-core, pa11y, Lighthouse, WAVE or IBM Equal Access results.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

testland/qa132026년 10월 30일 업데이트

Use when launching, auditing or governing an A/B test or online experiment design. Builds a per-experiment checklist and sign-off: pre-registered metric, power and guardrails, randomization unit and sample ratio mismatch checks, assignment, telemetry, peeking rules and novelty effects.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

testland/qa132026년 10월 30일 업데이트

Use when a PWA's manifest, icons or install handler change, install conversions drop, or an install test is flaky. Builds Playwright tests for the install flow: installability criteria, the beforeinstallprompt and userChoice chain, the iOS Safari path and display-mode standalone after install.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

testland/qa132026년 10월 30일 업데이트

Use when a spec and a test suite both exist but nobody can say which requirements are covered, before a release sign-off, an audit or planning test effort. Uses an LLM to map existing tests to spec sections, outputs a coverage matrix per spec ID and names the gaps. It does not write new tests.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

testland/qa132026년 10월 30일 업데이트

Use when tests should be generated from acceptance criteria, user stories or requirements with an LLM. Scores confidence per test case (self-assessment plus assertion, naming and completeness checks), batches uncertain cases for human review and emits tests in the team's existing framework.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

testland/qa132026년 10월 30일 업데이트

Use when a team wants richer test reports than JUnit XML: steps, attachments, per-test history, retries and severity or feature labels. Sets up Allure Report adapters for pytest, Jest, JUnit, TestNG, NUnit or Mocha, failure categories, history trends and the static HTML site as a CI artifact.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

testland/qa132026년 10월 30일 업데이트

testland의 스킬 모두 보기

이 스킬의 문제 신고