Testing map Devflare

Use one testing map so you know which Devflare page answers which testing question

Devflare’s testing story is layered: start with one real unit test, use and for the runtime-shaped harness, then jump to binding-specific guides or CI-focused pages only when the question changes.

The docs already explain starter tests, harness behavior, runtime-context caveats, transport round-trips, binding-specific testing, and automation. This page gathers those lanes into one map so you can open the right testing page first instead of re-deriving the docs structure from memory.

Best for: Finding the right testing doc before you disappear into the wrong rabbit hole
Default harness: plus helpers
Binding-specific docs: At the bottom of each binding overview page and in the binding testing index
Automation lane: for CI, preview checks, and workflow feedback

Start with one honest proof before you optimize the testing story

The safest Devflare testing habit is boring: prove one worker path with one real request first, then only add more harness machinery when a binding, background surface, or preview concern genuinely needs it.

The docs split testing into layers for this reason. A starter request test, a runtime-shaped harness page, binding-specific testing guides, and a CI/automation page each answer different questions. Trying to make one page carry all of that usually makes the guidance worse.

If the worker cannot answer one truthful request, the next testing abstraction is probably not the rescue mission you need.
Start route-level when the app behavior is the point, and binding-level when the binding itself is the point.
Keep one small proof test around even after the suite grows so the runtime contract stays visible.

The boring first loop is still the right default

import { afterAll, beforeAll, expect, test } from 'bun:test'

import { createTestContext, cf, env } from 'devflare/test'

beforeAll(() => createTestContext())

afterAll(() => env.dispose())

test('GET /health proves the worker boots', async () => {

const response = await cf.worker.get('/health')

expect(response.status).toBe(200)

})

Open the page that matches the question you actually have

Testing

Why tests feel native

Why it feels better

Open this when the question is less “how do I use the harness?” and more “why does Devflare testing feel so much smoother than the usual Worker setup?”

Quickstart

Your first unit test

Starter proof

Use this when the goal is simply to prove a worker boots, answers one request, and can be exercised through the real Devflare test harness.

Testing

createTestContext()

Harness

Use this when you need the real worker-shaped harness, autodiscovered surfaces, helper timing rules, and the testing helpers.

Testing

Binding testing guides

Binding index

Use this when the binding already exists and the open question is how to test KV, D1, R2, Queues, Durable Objects, AI, Vectorize, or another binding accurately.

Runtime

Runtime context

Runtime helpers

Open this when missing-context errors, getters, or runtime proxies are making tests feel harder to trace than they should.

Runtime

transport.ts

Bridge transport

Open this when a test needs a bridge-backed RPC call to return a real class instance instead of collapsing into plain JSON.

Ship & operate

Testing & automation

CI and release lanes

Use this page when the question changes from local test harness behavior to CI workflows, preview checks, and observable automation.

The right testing layer depends on what changed

If the question is...	Open this page first	Why
Can I prove the worker answers one real request?		It keeps the first check small and prevents the harness from becoming accidental ceremony.
Why does Devflare testing feel smoother than the usual Worker setup?		It explains the unified env, bridge-backed bindings, runtime helper surfaces, and direct Durable Object story.
How does the default runtime-shaped harness behave?		It documents autodiscovery, , helper timing, and when the harness waits for background work.
How should I test this specific binding?		Each binding has its own testing page with the right default harness and escalation path.
Why are getters or proxies failing in a test?		The runtime-context page explains when helper APIs can read the active request, env, ctx, event, and locals.
Why is a custom class not round-tripping in a test?		Transport docs explain the extra serialization hook for bridge-backed calls.
How should this fit into CI or preview validation?		Automation guidance belongs on the CI-facing page, not in the local harness docs.

One page per question is a feature

Devflare’s testing docs are intentionally split so starter tests, binding nuance, runtime context, and automation do not blur into one giant advice blob.

Binding-specific testing pages already exist — they were just easy to miss

Each binding overview page already links its testing and example pages. That means the binding-specific testing content is already in the library, but it was discoverable mostly if you were already reading the right binding page.

Use the binding testing index when you know which binding changed and want the testing guide directly. Use the binding overview page first when you still need the config shape, runtime usage, or local support notes before the tests make sense.

Testing

Binding testing guides

Binding index

Jump straight to the testing page for KV, D1, R2, Durable Objects, Queues, AI, Vectorize, Hyperdrive, Browser Rendering, Analytics Engine, or Send Email.

Open the binding overview page when you need config or runtime context first.
Open the binding testing page when the binding already exists and the question is purely about the right harness or escalation path.
Remote-oriented bindings like AI and Vectorize deliberately have a different testing posture from KV or D1, and the testing guides say that out loud.

Why tests feel native

Devflare’s standout testing trick is that the same config, bindings, env surface, runtime helpers, and even direct Durable Object method calls can stay available in Bun tests without a hand-built fake layer in the middle.

createTestContext()

Start tests with so the same config, bindings, routes, and handler surfaces the app uses in real runtime flows are available in Bun tests.