Testing Bindings

Test Hyperdrive the way Devflare expects it to run

Hyperdrive gives Workers a pooled, Cloudflare-managed connection path to existing PostgreSQL databases.

Hyperdrive testing should start with a local connection string, then add a focused query test against the database shape your app actually uses.

Devflare can provide the binding locally. Your test database still has to exist, just like any other local Postgres dependency.

Best for: Local PostgreSQL integration paths and connection-string-driven app code
Default harness: or with
Escalate when: The app depends on real preview isolation or actual Postgres query behavior

Start with the default test loop

Start with one small assertion that the binding exposes the local connection string your database client expects.

Then add focused integration tests against the actual local database path instead of involving Cloudflare for application-owned SQL behavior.

A conservative Hyperdrive smoke test

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

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

beforeAll(() => createTestContext())

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

test('Hyperdrive binding exposes local connection info', () => {

expect(env.DB).toBeDefined()

expect(env.DB.connectionString).toContain('localhost')

})

Use in config when the test should run without Cloudflare.
Use when a pure unit test needs a Hyperdrive-shaped binding without Miniflare.
Keep one higher-level integration path for the real database behavior you actually care about.
If preview isolation matters, test the fallback or dedicated preview strategy explicitly.

Do not run local Hyperdrive tests against a shared production database.
If the worker truly depends on live query behavior, prefer an integration test against a real database path.
Preview-specific Hyperdrive expectations deserve a dedicated test because automatic cloning is not guaranteed.

Keep database ownership explicit

Devflare owns the binding wiring; the test suite owns the local database lifecycle and seed data.

Hyperdrive uses the same normalize-and-resolve pattern as KV and D1, and local runtime config is driven by the binding connection string.

This example uses Hyperdrive in an application route that reads one product from PostgreSQL.