Course lesson 58 · Wrapping Up
Writing Tests
The testing section demonstrates unit tests around business logic, using mocks to isolate database calls, workflow scheduling, and Durable Object dependencies. Queue-handler tests check forwarded data, operation order, and error behavior. Tracker tests cover alarm creation, avoiding duplicate alarms, broadcasting a batch to multiple clients, advancing offsets, and deleting older clicks.
Primary source: course video 58 · Supplied English subtitles · 00:14:52.
Understand the idea
- A mock substitutes controlled behavior for an external dependency so a test can focus on application decisions.
- Call-order checks are useful when later work depends on an earlier operation succeeding.
- Failure-path tests make the intended relationship between database writes and workflow scheduling explicit.
- Durable Object logic can be tested with mocked SQL, storage, and sockets, but this requires more setup.
- The instructor prefers small callable units of business logic over deeply embedded chains that are difficult to exercise.
What the course does
- Mock click persistence and workflow scheduling in the queue-handler tests and reset mocks between cases.
- Pass a representative click event and check that the expected data reaches persistence.
- Verify that persistence precedes workflow scheduling, and that a simulated database error prevents dependent work.
- Construct mocked Durable Object storage, SQL, and socket dependencies for tracker tests.
- Test the no-alarm and existing-alarm branches of adding a click.
- Trigger an alarm with a prepared batch and two sockets, then assert delivery, offset updates, and cleanup.
Watch for
- These examples illustrate the instructor’s testing preferences, not proof that request routing or platform integration never needs testing.
- The tests mock Cloudflare behavior and therefore do not validate actual runtime storage, alarm, or WebSocket semantics.
- Several simple call-through tests are explicitly described as scaffolding for future, more substantial business logic.
Recall before revealing
What can a mocked tracker test prove, and what can it not prove?
Reveal the explanation
It can check the application’s decisions and calls for controlled inputs; it cannot prove that the real Cloudflare runtime behaves exactly like those mocks.
Try it
Design one meaningful failure-path test for the tracker or queue handler and state the behavior it protects.
Check your result
Your test links a realistic failure to an explicit business requirement, rather than merely repeating the implementation’s call sequence.
Practice prompts and answer checks are added teaching material. Answer from memory first, then compare and explain any difference.
Rewatch only what you need
Open this lesson in your original course library and seek to the times below. Videos are not hosted on this site.
- 00:02:32 — Mock queue-handler dependencies
- 00:04:02 — Assert persistence before workflow scheduling
- 00:05:04 — Test database failure behavior
- 00:09:40 — Alarm creation and existing-alarm branches
- 00:12:13 — Broadcast and cleanup assertions
Companion primary documentation: Cloudflare Workers Vitest integration. For recorded API names, commands, limits, and prices, check the version you use.