> ## Documentation Index
> Fetch the complete documentation index at: https://demo-travel.webbinghub.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# How Omnibeds is tested

> The four kinds of Omnibeds tests: unit tests with an in-process database, boundary tests that guard the layers, end-to-end tests of real screens, and live supplier tests.

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](https://demo-travel.webbinghub.io/docs/quickstart.md).

| Kind | Command | Answers |
| - | - | - |
| Unit | `npm test` | Does each piece do what it should? |
| Boundaries | part of `npm test` | Are the layers still apart? |
| End to end | `npm run test:e2e` | Does the real app work, screen by screen? |
| Live suppliers | `npm run test:live` | Do the real suppliers still accept what we send? |

## 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.

> [!TIP]
>
> 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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.