Testing index Devflare

Open the right binding testing guide instead of reconstructing the test story from scratch

Every binding overview page already links a hidden testing guide. This page collects those guides in one place so you can jump straight to the right harness, caveats, and escalation path for the binding that changed.

Binding testing is not one-size-fits-all. KV, D1, R2, Durable Objects, Queues, and several other bindings are strong local-first stories, while AI, Vectorize, and a few infrastructure-heavy bindings need more remote or higher-fidelity checks sooner. Use this page when you know the binding but do not want to hunt through the whole binding library first.

Best for: Jumping straight to the right binding-specific testing guide
Where the links also live: At the bottom of each binding overview page in the “Go deeper” section
Default pattern: Usually plus the real binding or helper surface
Notable exceptions: AI and Vectorize are remote-oriented, and some other bindings need higher-fidelity checks sooner

Use this page as the index, but remember where the links already live

The binding library intentionally keeps only the main binding overview pages visible in the sidebar. The testing pages are still real docs pages, but they stay linked from the bottom of each binding overview so the sidebar does not turn into a twelve-level nesting doll.

That is great once you already opened the right binding page. This index is for the opposite moment: you know the binding that changed and you want the testing guide immediately.

Testing

Testing overview

Map

Use the broader testing map when you are not yet sure whether the next question belongs to starter tests, binding guides, runtime context, or automation.

Open the binding overview page first when you need authoring, runtime, or preview context before the tests make sense.
Open the testing guide first when the binding already exists and the only remaining question is how to test it honestly.
Use when you need the bigger map across starter tests, harness behavior, binding guides, runtime helpers, and automation.

Open the testing guide for the binding that actually changed

Binding guide

Testing KV

`createTestContext()` plus `env.CACHE` or `cf.worker.fetch()`

Use the default test harness first. KV is one of the bindings Devflare supports best in local tests. Open the KV overview first when you need the full binding story, or jump straight here when the only open question is how to test it honestly.

Binding guide

Testing D1

`createTestContext()` with `env.DB` or `cf.worker.fetch()`

D1 is one of the easiest bindings to test meaningfully with Devflare because the local runtime already speaks the same database API your worker uses. Open the D1 overview first when you need the full binding story, or jump straight here when the only open question is how to test it honestly.

Binding guide

Testing R2

`createTestContext()` with `env.ASSETS` or `cf.worker.fetch()`

R2 is local-friendly, which means you can test real object operations without inventing a storage adapter just to get off the ground. Open the R2 overview first when you need the full binding story, or jump straight here when the only open question is how to test it honestly.

Binding guide

Testing Durable Objects

`createTestContext()` with the real DO namespace in `env`

Durable Objects are well-supported in the default Devflare harness, which means you can test real object behavior without hand-building a fake namespace first. Open the Durable Objects overview first when you need the full binding story, or jump straight here when the only open question is how to test it honestly.

Binding guide

Testing Queues

`createTestContext()` plus `cf.queue.trigger()`

Queue testing is one of the places where Devflare’s helper surface feels especially good because the queue trigger already knows how to drive the real handler shape. Open the Queues overview first when you need the full binding story, or jump straight here when the only open question is how to test it honestly.

Binding guide

Testing AI

`createTestContext()` after remote mode is enabled, plus `shouldSkip.ai`

The right AI test strategy is selective: use remote mode when you mean to test inference, and skip cleanly when the environment is not allowed to do that. Open the AI overview first when you need the full binding story, or jump straight here when the only open question is how to test it honestly.

Binding guide

Testing Vectorize

`createTestContext()` in remote mode plus `shouldSkip.vectorize`

The right Vectorize tests are targeted remote checks: a small insert or query, a clear skip condition, and a real index behind the binding. Open the Vectorize overview first when you need the full binding story, or jump straight here when the only open question is how to test it honestly.

Binding guide

Testing Hyperdrive

`createTestContext()` plus small binding or smoke checks

Hyperdrive testing should start smaller and more cautiously than D1 testing: prove the binding exists, then add targeted integration where the real database path matters. Open the Hyperdrive overview first when you need the full binding story, or jump straight here when the only open question is how to test it honestly.

Binding guide

Testing Browser Rendering

A narrow browser route exercised through the dev server, a preview URL, or another integration-style path

Browser tests should usually be integration-flavored: either drive the worker in dev or exercise a thin smoke path that proves the binding can launch and fetch. Open the Browser Rendering overview first when you need the full binding story, or jump straight here when the only open question is how to test it honestly.

Binding guide

Testing Analytics Engine

A thin worker test or explicit mock around `writeDataPoint()`

Analytics Engine tests should stay thin: verify that the worker writes a data point, not that you can recreate Cloudflare analytics locally. Open the Analytics Engine overview first when you need the full binding story, or jump straight here when the only open question is how to test it honestly.

Binding guide

Testing Send Email

`createTestContext()` plus `env.TRANSACTIONAL_EMAIL.send(...)`

Send Email is stronger locally than many platform-service bindings because outbound email can be exercised in the default harness, while inbound email has its own related helper surface. Open the Send Email overview first when you need the full binding story, or jump straight here when the only open question is how to test it honestly.

The testing posture is not identical for every binding

Binding	Testing posture	Default harness
KV	First-class local runtime and tests	plus or
D1	First-class local runtime and tests	with or
R2	First-class local runtime and tests	with or
Durable Objects	First-class local runtime and tests, including cross-worker references	with the real DO namespace in
Queues	First-class local runtime and queue-trigger tests	plus
AI	Remote-oriented; local tests require remote mode	after remote mode is enabled, plus
Vectorize	Remote-oriented; local tests require remote mode or explicit mocks	in remote mode plus
Hyperdrive	Supported, but with a narrower proven local test story	plus small binding or smoke checks
Browser Rendering	Supported, but the strongest story is dev server and integration rather than a dedicated test helper	A narrow browser route exercised through the dev server, a preview URL, or another integration-style path
Analytics Engine	Supported, but usually tested through integration or thin mocks	A thin worker test or explicit mock around
Send Email	First-class outbound local support; distinct from inbound email event testing	plus

Different defaults are a good thing

KV, D1, R2, and Queues should not be documented like remote AI inference, and remote AI inference should not be documented like local KV. The different testing guides are there to keep those truths visible.

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.

Svelte in workers

When a worker-only fetch surface or Durable Object imports , add the Svelte compiler to . That compilation belongs to Devflare’s worker bundler, not the main Vite plugin chain.