A monitoring tool that breaks silently is worse than no monitoring: you trust a green dashboard that is lying to you. So the thing we test hardest is whether checks actually run and report, not just whether the code compiles. Here is how oo-workers is tested.
Three layers#
- Unit tests run in-source with
bun test, fast, for pure logic like the assertion evaluators. - Integration tests spin real infrastructure with testcontainers: a real Postgres, a real Redis, and real S3-compatible storage, started fresh for the run and torn down automatically. Nothing mocks the database or the queue, because the bugs worth catching live in how those pieces actually behave together.
- End-to-end tests drive the real dashboard in a browser with Playwright.
Test the behavior, not that it ran#
The trap with a monitoring product is the vacuous test: assert a function was called, watch it pass, and ship a check that does not actually check anything. We try to assert the real outcome instead.
- The backup test does a destructive round-trip: back up, wipe, restore, then assert byte equality on the restored artifacts. As the backup post put it, a backup you have never restored is a guess.
- The live-update test seeds a monitor, forces one run, and asserts the dashboard's latency cell goes from its placeholder to a real millisecond value with no reload. It checks that the operator actually sees the result, not just that an event fired.
- The cross-process event bus has a dedicated test that publishes from one connection and asserts the event arrives on another, exactly once. It fails the moment anyone reverts the bus to a single-process shortcut.
Why real infra#
Mocks encode your assumptions, and the bugs that matter are where reality disagrees with them: a transaction that does not roll back, an event that does not cross a process, a query that behaves differently on real Postgres than on a stub. Spinning the real thing in a container costs a few seconds a run and catches the class of bug a mock would wave straight through.