Testing Bindings

Test Send Email the way Devflare expects it to run

The send_email binding lets Workers send outbound email through Cloudflare Email Routing.

Send Email is stronger locally than many platform-service bindings because outbound email can be exercised in the default harness, while inbound email has its own related helper surface.

That means the docs should teach both the outbound binding test and the conceptual split from inbound email event tests, so people do not mix the two up.

Best for: Outbound notification checks and address-restriction behavior
Default harness: plus
Escalate when: The system has external email delivery requirements beyond the local binding path

Start with the default test loop

Start with one direct outbound send call through the binding and verify the success or allow-list behavior you actually care about.

If you are testing inbound processing, switch mental models entirely and use the email event helper path instead of forcing everything through the outbound binding.

Testing an outbound Send Email binding

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

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

beforeAll(() => createTestContext())

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

test('sends an outbound transactional email', async () => {

await expect(env.TRANSACTIONAL_EMAIL.send({

from: 'noreply@example.com',

to: 'ops@example.com',

subject: 'Smoke check',

text: 'Hello from Devflare'

})).resolves.toBeUndefined()

})

The helper surface to remember

Use the outbound binding directly when the worker is sending mail.
Use the inbound helper surface ( from ) when the worker is handling inbound email in .
Keep address restrictions visible in tests when those restrictions are part of the safety story.

When to move beyond the default harness

Do not document inbound email helper tests as if they were proof of the outbound binding path, or vice versa.
If external delivery or provider-side verification matters, add a separate integration lane rather than overfitting the local harness.
The local harness is great for binding behavior, but email product workflows often still need a higher-level end-to-end check.

Two email stories, one docs rule

Keep outbound binding docs and inbound handler docs adjacent in your head, but separate on the page. That is how people avoid testing the wrong thing.

Send Email internals

Send Email compiles into Wrangler output, normalizes message input at runtime, and supports local address restrictions instead of treating email as an unbounded free-for-all.

Send Email example

This example keeps outbound email explicit: one binding, one recipient rule, one worker path that sends one message.