Test the runtime shape you actually ship, then keep automation thin and observable
Keep local harness detail on the dedicated testing pages, then promote only the right runtime-shaped checks into thin, observable automation.
Devflare’s testing story is intentionally layered. The local harness pages own and binding-specific nuance; this page owns the CI-facing question of which checks should move into preview validation, release automation, and workflow feedback.
- Best for
- CI-facing testing policy, preview validation, and thin release automation
- Local harness owner
- plus binding testing guides
- Important nuance
- is not a full drain
- Workflow companion
Let the local testing pages own local harness detail
This page used to repeat too much of the local harness story. The better split is simpler: keep behavior, autodiscovery, and binding-specific harness detail on the dedicated testing pages, then use this page for the question “what should actually run in automation?”
That keeps local test design and CI policy from drifting into two slightly different copies of the same documentation.
Testing
Testing overview
MapUse the map page first when you need to choose between starter tests, the harness page, binding-specific guides, runtime context, or CI-facing validation.
Testing
createTestContext()
HarnessThis is the canonical page for autodiscovery, helper timing, transport-aware round-trips, and the real helper behavior.
Testing
Binding testing guides
Binding indexOpen these when the binding changes the honest testing posture and the local harness rules are no longer one-size-fits-all.
A cleaner split keeps both pages better
The harness pages should own local helper behavior. This page should own what gets promoted into automation and how that automation stays understandable.
Carry only the automation-facing timing rules into CI
Automation does not need the whole local harness manual, but it does need the timing rules that commonly produce flaky checks or false confidence.
The main habit is to promote the check that matches the behavior you actually need to trust instead of assuming every helper has the same completion contract.
| When the check depends on... | Prefer | Why |
|---|---|---|
| side effects from an HTTP handler | Assert the side effect directly or move to a higher-fidelity check. | returns when the handler resolves, not when every background task drains. |
| Queue, scheduled, or tail background work | , , or | Those helpers wait for their background work before they return, so they are a better fit for async side-effect assertions. |
| Binding-specific or transport-specific behavior | The binding guide or page first | Different bindings and bridge-backed values have different honest harness rules, and the local testing pages already own those details. |
Do not promote the wrong completion contract into CI
If a test depends on effects being complete, a plain assertion may be too early. Keep that nuance visible in automation instead of discovering it from flaky builds later.
Promote the smallest useful checks into automation
Ship & operate
Preview operations
Preview lifecycleUse the preview page when a runtime check depends on preview-scoped resources, reconciliation, retirement, or cleanup behavior.
Ship & operate
Production deploys
Deploy targetsUse the production page when the check is really about the deploy target, compiled output, or preflight inspection before release.
Ship & operate
GitHub workflows
CI/CDUse the workflow page when those promoted checks need to become reviewable Actions jobs with explicit triggers, permissions, and feedback.
- 1
Prove the behavior locally with or the binding-specific guide first.
- 2
Choose one or two runtime-shaped smoke checks that are worth rerunning in CI because they protect the deploy boundary, not because they are merely easy to copy.
- 3
Use preview validation when routing, preview-owned resources, or branch-scoped behavior is the real risk instead of trying to force every concern through one unit-style check.
- 4
Publish one visible summary or feedback artifact so reviewers can tell what passed without spelunking through raw logs.
Automation should stay thin and observable
The repository workflow pieces are intentionally split between deploy logic and GitHub feedback logic. That keeps Cloudflare state changes separate from PR comments, deployment records, or other reporting behavior.
Caller workflows should own branch naming, permissions, environment selection, and post-deploy feedback decisions, while reusable actions should stay focused on one deploy or one reporting job at a time.
- Keep one package, one explicit target, and one visible verification result in the same workflow lane whenever possible.
- Split deploy execution from GitHub feedback so reporting can fail or retry without becoming a second deploy path.
- Prefer workflow summaries, PR comments, or deployment records that show the result directly instead of forcing reviewers into raw logs.
Thin workflows age better
When a release is stressful, a small workflow that clearly says what it deploys and what it reports is much easier to trust than a giant do-everything pipeline.
Thin preview deploy step
Previous
Preview operations
The preview registry is D1-backed and gives Devflare a durable record of preview, alias, and deployment state so cleanup and reconciliation do not have to depend on fragile one-off scripts.
Next
Storage strategy
Use this page to choose between KV, D1, R2, and Hyperdrive. Once the shape is clear, open the binding-specific guide for authoring, testing, and examples instead of reading several smaller pages that all repeat the same decision badly.