Testing Bindings

Test AI the way Devflare expects it to run

Workers AI lets Workers run Cloudflare-hosted machine-learning models through an env binding.

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.

Trying to force AI into the same local-only expectations as KV or D1 leads to misleading tests. Devflare already gives you the right gates — use them.

Best for: Remote inference checks and binding-level AI smoke tests
Default harness: after remote mode is enabled, plus
Escalate when: The AI call is expensive, flaky, or business-critical enough to need a separate release gate

Start with the default test loop

Start with a tiny inference call and a tiny assertion. The goal is to prove that the binding works and the worker can talk to the intended model, not to test your entire AI product in one unit test.

Enable remote mode first — for example with or (or another truthy value) in automation — and skip explicitly when the environment still cannot support remote AI instead of forcing the test to fail in noisy ways.

A remote-oriented AI test

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

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

beforeAll(() => createTestContext())

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

const skipAI = await shouldSkip.ai

describe.skipIf(skipAI)('AI binding', () => {

test('runs a tiny inference request', async () => {

const result = await env.AI.run('@cf/meta/llama-3.2-1b-instruct', {

messages: [{ role: 'user', content: 'Reply with OK only.' }],

max_tokens: 4

})

expect(result).toBeDefined()

})

The helper surface to remember

Enable remote mode before expecting to inject a real AI binding, for example with in automation.
Use to make remote prerequisites explicit in the test file itself.
Keep AI assertions small enough that failures teach you about the binding path, not about prompt engineering drift.
Use non-AI stubs above the worker layer when the app UI only needs a placeholder during purely local development.

When to move beyond the default harness

Remote AI tests are not free; keep them targeted and intentional.
If the worker depends on , test that path outside the remote AI helper because the helper warns and does not implement gateway mode.
If the worker contract is business-critical, move AI smoke tests into an explicit integration or release lane rather than running them everywhere.
Do not confuse local app mocks with proof that the real AI binding path works.

Skip is not weakness here

For remote bindings, a clear skip condition is often more trustworthy than a forced local pseudo-test that never exercised the real platform.

AI internals

AI has a smaller compiler story than storage bindings, but a more explicit auth and remote-runtime story.

AI example

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