Testing Bindings

Test Services the way Devflare expects it to run

Service bindings let one Worker call another Worker without routing through a public URL.

Service bindings are one of the clearest Devflare wins in multi-worker apps: you can keep the real worker boundary and still prove it through the default local harness.

Start with , then call the bound service through the generated env shape. That proves the config relationship, the local worker family, and the callable contract in the same language the app itself uses.

Best for: Gateway-to-service calls, entrypoint wiring, and typed multi-worker behavior
Default harness: plus
Escalate when: The risk is worker naming drift, preview topology, or compiled output correctness

Start with the default test loop

The shortest honest test is usually one real service call through the generated env binding. That already proves the config relationship and the callable surface.

Keep one test for the default worker entry and one for any named entrypoint that matters operationally.

Testing a service binding through the env

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

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

beforeAll(() => createTestContext())

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

test('service binding calls the default worker export', async () => {

expect(await env.MATH_SERVICE.add(5, 3)).toBe(8)

})

The helper surface to remember

Use the bound env service directly when the service relationship is the thing you want to prove.
Keep named entrypoints explicit in tests so they do not quietly drift from the config contract.
Run whenever service entrypoints change so env autocomplete and generated types stay in sync.

When to move beyond the default harness

Local tests prove the callable relationship, not that your preview or production worker names are what you intended.
If the service graph is business-critical, validate compiled output before deploys as well.
Test naming and topology at preview or build time when those are the real failure modes.

A typed local call is not the whole deploy story

The local harness tells you the relationship is modeled correctly. A preview or build check tells you the resolved worker names are still the ones you expect.

Services internals

Devflare resolves referenced worker configs, bundles the linked worker surfaces, and then exposes those services as local multi-worker bindings.

Services example

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