Testing Bindings

Test Durable Objects the way Devflare expects it to run

Durable Objects give Workers a named place for stateful coordination, storage, and alarms.

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.

That support extends to cross-worker DO scenarios too, as long as the config relationships are explicit. The main testing question is whether you are checking local object behavior or deployment caveats.

Best for: Local stateful behavior, object methods, and cross-worker DO wiring checks
Default harness: with the real DO namespace in
Escalate when: The question is preview URLs, migrations, or branch-scoped deploy behavior

Start with the default test loop

Start by creating the test context and calling the object through its real namespace. That proves the binding, the identity lookup, and the object behavior in one go.

Keep one test close to the object semantics even if your app later wraps DO access behind services or helper modules.

Testing a Durable Object through the real namespace

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

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

beforeAll(() => createTestContext())

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

test('the counter object increments', async () => {

const counter = env.COUNTER.getByName('main')

expect(await counter.increment()).toBe(1)

expect(await counter.increment()).toBe(2)

expect(await counter.getValue()).toBe(2)

})

The helper surface to remember

Use the real DO namespace in whenever possible instead of a fake interface.
If the object is reached through a route or another worker, keep a worker-level test around as well.
Use cross-worker refs in config rather than loose string conventions so the test context can understand the relationship.

When to move beyond the default harness

Local DO tests do not replace migration reviews or branch-scoped preview checks.
If the real risk is deployment naming or preview topology, write a higher-level preview test instead of stretching the local harness past its job.
DO apps often need stronger preview isolation than a same-worker upload path can give them.

Separate object behavior from preview behavior

The default harness is excellent for object logic. It is not a substitute for the preview strategy decisions that DO-heavy apps still need.

Durable Objects internals

Durable Object bindings normalize into a stable binding shape, compile into Wrangler , and participate in Devflare’s own DO bundling path.

Durable Objects example

A real Durable Objects application path with config and runtime code kept side by side.