Skip to main content
Omnibeds has four kinds of tests, and each one answers a different question. Run the first three before every commit; run the live tests when you change a supplier adapter. The commands are on Run and test.

Unit tests

Unit tests (Vitest, in tests/) cover the domain: pricing, guest names by each supplier’s rules, quotes, trips, mapping, the orchestrator’s retries and breaker, and every command’s checks. Tests that need a database run against PGlite, an in-process Postgres, built from the same migrations as production. tests/migrations.test.ts checks a fresh database gets every migration once and every table the code uses, and that a failed migration rolls back.

Boundary tests

tests/boundaries.test.ts and tests/app-layer.test.ts keep the architecture from drifting. They fail when:
  • a command has no route, or its route file doesn’t serve its method,
  • a route that isn’t infrastructure does more than call a command,
  • code in lib/ imports from components/,
  • a screen imports server code,
  • a screen writes a command’s URL instead of calling api().
They also check that each command’s checks run for every caller and that errors keep the one format.

End-to-end tests

Playwright tests in e2e/ start the app and drive the real screens. They cover, among others: booking step by step (with a placeholder name prompted), a cheaper equivalent offered and taken, the price-drop switch, quotes with versions, extras, the client link and acceptance, trips and travellers, traveller changes and rebooking, booking documents, the live booking view with its fallback, and every screen in both languages on phone and desktop.
Tests that make a booking cancel it at the end, so the data stays clean.

Live supplier tests

The live suite (vitest.live.config.ts) calls the real suppliers’ test environments: search, price check, book and cancel. It spends real quota, so it isn’t part of the normal run. Every booking it makes is cancelled in a finally block, even when the test fails.