Testing Bindings

Test Browser Rendering the way Devflare expects it to run

Browser Rendering lets Workers drive a headless browser for screenshots, PDFs, and page automation.

Browser tests should usually be integration-flavored: either drive the worker in dev or exercise a thin smoke path that proves the binding can launch and fetch.

That is more truthful than pretending the browser binding has the same helper depth as or .

Best for: Launch smoke tests, PDF generation routes, and browser-backed worker endpoints
Default harness: A narrow browser route exercised through the dev server, a preview URL, or another integration-style path
Escalate when: A real browser workflow is mission-critical or too heavy for ordinary test runs

Start with the default test loop

Keep the worker-side browser entry small enough that one smoke path can prove it launches, opens a page, or returns a generated artifact.

If the real logic is bigger — for example a full PDF renderer DO — write one narrow end-to-end check and keep the rest of the code tested at smaller layers.

A tiny dev-server browser smoke check

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

const baseUrl = process.env.DEVFLARE_TEST_URL ?? 'http://127.0.0.1:8787'

test('browser-backed route responds', async () => {

const response = await fetch(new URL('/browser-health', baseUrl))

expect(response.ok).toBe(true)

})

The helper surface to remember

Prefer one narrow worker route or DO method for browser tasks so the binding path stays testable.
Drive that route through the dev server, a preview URL, or another integration path when browser launch itself is the thing under test.
If you want Bun-only unit tests, stub above the browser boundary instead of expecting to create a browser binding for you.
Treat browser local checks as smoke tests unless the app really needs a heavier dedicated lane.

When to move beyond the default harness

No dedicated browser helper surface means you should test the worker boundary or integration path instead of reaching for fictional convenience APIs.
is still useful around surrounding worker code, but it is not a browser-specific helper that automatically populates for you.
Browser workloads are heavier than typical request tests, so they deserve intentional scheduling in CI.
If the route depends on browser proxying or WebSockets, test that path in an environment close to the real dev server.

Smoke test the launch path, not the whole internet

Browser bindings get expensive fast. One honest launch or render smoke path is usually better than an enormous browser suite that nobody trusts.

Browser Rendering internals

Browser Rendering support in Devflare is more than a config pass-through: the dev server starts a browser shim and a binding worker that line up with Cloudflare and puppeteer expectations.

Browser Rendering example

This example shows the real browser path people actually need: one binding, one title-read route, and one smoke check through the dev server.