Testing Bindings

Test Rate Limiting the way Devflare expects it to run

Rate Limiting bindings let Workers enforce fixed-window limits from inside application code.

Test Rate Limiting by choosing the local harness that matches the product boundary instead of reaching for Cloudflare by default.

The first test should prove application control flow. Escalate to Wrangler remote binding or deployed tests only when the Cloudflare-hosted behavior is the thing under test.

Best for: login throttles, per-user limits, and API guardrails that can use Cloudflare fixed windows
Default harness: or
Escalate when: The assertion depends on Cloudflare-hosted product behavior rather than the app calling the binding correctly

Start with the default test loop

Keep the first test small. Name the binding, call the one method your route uses, and assert the behavior your app owns.

When Cloudflare owns the interesting behavior, mark that as a remote/deployed lane instead of building a local fake that claims too much.

Pure unit test for rate-limit branching

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

import { createMockEnv } from 'devflare/test'

test('blocks the second call in the same window', async () => {

const env = createMockEnv({

rateLimits: {

LOGIN_RATE_LIMIT: { limit: 1, period: 60 }

}

})

expect((await env.LOGIN_RATE_LIMIT.limit({ key: 'user-1' })).success).toBe(true)

expect((await env.LOGIN_RATE_LIMIT.limit({ key: 'user-1' })).success).toBe(false)

})

The helper surface to remember

Use or for config-backed local worker tests.
Use / for pure unit tests.
Use or an explicit integration lane when the test needs Cloudflare credentials or a local Docker/Podman engine.

When to move beyond the default harness

Cloudflare owns account namespace ids and production enforcement, but the local limiter is useful for deterministic app tests.
Do not let a low-fidelity mock become product documentation. Keep mocks framed as application-flow tools.
If a test would mutate paid or remote Cloudflare state, gate it separately from ordinary unit tests.

Local tests should be honest

For Rate Limiting, passing locally means the Devflare contract and app flow are correct. It does not automatically prove every hosted Cloudflare behavior.

Rate Limiting internals

Rate Limiting compiles from to Wrangler , with local/test behavior called out explicitly.

Rate Limiting example

A compact Rate Limiting recipe with config and worker usage in one application path.