Testing Bindings

Test Queues the way Devflare expects it to run

Queues let Workers send messages to background consumers with retries, batching, and dead-letter handling.

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.

That means you can test a queue consumer without bootstrapping your own fake message batch or pretending the queue handler is just a random function.

Best for: Queue consumer behavior, retries, and queue-driven side effects
Default harness: plus
Escalate when: You need to verify preview queue lifecycle or deployment topology

Start with the default test loop

Start by triggering the consumer directly. That is usually the shortest path to proving retries, acknowledgements, and side effects like KV writes or database updates.

If the queue is reached from an HTTP route, keep one route-level test too so the enqueue step itself stays visible.

Testing a queue consumer through Devflare helpers

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

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

beforeAll(() => createTestContext())

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

test('queue consumer stores a processed result', async () => {

await cf.queue.trigger([

{

id: 'job-1',

body: { id: 'task-1', type: 'process', createdAt: Date.now() }

}

])

expect(await env.RESULTS.get('result:task-1')).not.toBeNull()

})

The helper surface to remember

Use when the consumer behavior is what you care about.
Use when you want to prove enqueue code in the same runtime path.
Queue tests are a good place to assert retries or DLQ behavior because the helper already understands the message shape.

When to move beyond the default harness

Queue helper success does not automatically prove your preview or deploy queue topology is right.
If the route-to-queue path matters, keep one request test so the enqueue boundary stays visible.
Batch semantics and failure handling deserve their own tests instead of one giant everything-at-once assertion.

Queue tests are allowed to be direct

You do not need to sneak queue behavior behind HTTP if the queue consumer itself is the thing you want confidence in.

Queues internals

Queue config is compiled into explicit producer and consumer blocks, with preview resource materialization available for both queue names and DLQs.

Queues example

This starter example wires one producer, one consumer, and one stored result so you can see the whole queue loop without ceremony.