Write your first unit test with the built-in Devflare harness
Take the same starter worker from the previous page and add one request test through so the first check uses the same runtime shape the worker will actually run.
You do not need a custom mock stack to get confidence. Keep and as they were, add one file, and prove the worker responds once.
- Best for
- The first runtime-shaped test in a new worker package
- Main helper
- plus
- First proof
- One request, one status check, one response assertion
Write one honest test
The easiest continuation from the first worker page is not a refactor. It is one new test file beside the same config and fetch handler.
gives that test the same runtime shape Devflare manages locally. Keep the first assertion narrow: one request, one status check, one response body. That already proves the worker, the harness, and your local setup are all talking to each other correctly.
Keep the first test boring
If the first test is obvious, failures are obvious too. That is what you want while the worker is still tiny.
Keep the first worker, add one test file
The config and fetch handler stay exactly the same. The only new authored file is the test.
What this unlocks next
- You can keep the same harness when the worker grows routes, queue consumers, scheduled handlers, or other runtime surfaces.
- One request-level smoke test is still useful even after helpers and abstractions appear around the worker.
- When you need more test helpers, open for the full helper map.
The next docs page when tests grow up
Use when you need more than one request test and want the full runtime helper surface laid out clearly.
Previous
Your first worker
Start with one config file, one fetch handler, and generated types before you branch into routes, bindings, frameworks, or a deeper test setup.
Next
Your first route tree
The first route-tree step should only change project shape: config, request-wide middleware, one route, and one worker-level test.