Testing

This guide documents the unit-testing conventions used in @xen-orchestra/web, as established across the pool, host and vm modules. Follow it when adding tests for a new module, composable, utility or component.

Start with Assert behaviour, not implementation — it is the rule the rest of this guide serves.

What to test first

A fixed priority, not a preference:

Components that make up a page (modules/<mod>/components/**) — top priority, equal with the next entry
Composables and utilities (*.composable.ts, *.util.ts) — top priority
Pages (src/pages/**) — lowest, and deliberately thin: assert which components render, never their values

Testing a page is a different job from testing a component, and the component is the more valuable one. A component should not carry much complex logic — when it does, extract that into a composable or utility and test it there.

Only the app's own behaviour

An XO 6 test covers what the app decides, never what @xen-orchestra/web-core does on its own: a side panel opening on a selection, a store re-expanding on a resize, a select opening its options all belong to the web-core tests. A web-core component may be rendered beside the code under test when the app's rule depends on it, but the assertion must be about that rule: a test that still passes once the app's code is removed is testing web-core and is deleted, not written. A state the app sets on a web-core component (busy, disabled, selected, a table state…) is asserted through that component's props (getUiButton(wrapper, label).props('busy')), never through the DOM it renders for it; a user action clicks the real <button> (getButton(wrapper, label)). A composable member that only forwards to a web-core store gets no test of its own. Selects: see Testing components.

Getting started

Assert behaviour, not implementation — the one rule that outranks the others
Test runner — Vitest setup and the commands to run a suite

Writing a test

File layout and structure — where a test lives, how it is named, how it is organised
Setup: prefer helpers over beforeEach — local helpers, and the shared use<X>EnhancedData ones
Test data factories — the src/test/create* factories and how to use them

What you are testing

Testing pure utilities — *.util.ts, called directly
Testing composables — mountComposable, reactivity, useI18n
Testing components — mount, querying rendered output, and what happy-dom cannot do
Mocking dependencies — the typed vi.mock form, and the network stub

2.9 KiB Raw Blame History