Tests are useful only when they run automatically on every change. A suite run by hand and by mood protects nothing: a regression is noticed already in production. CI's job is to make checking inevitable: on every push and pull request the machine runs the same pipeline, and a red result blocks the merge. A local green is a hypothesis; a green in CI is confirmation on a clean, reproducible machine.

The pipeline is built in a clear order, from cheap to expensive. First npm ci - installation strictly by the lockfile, without willful version bumps. Then fast checks: lint and typecheck as a separate step, because tests do not replace tsc --noEmit. Next the tests themselves in CI mode, and only at the end build. This order gives fast failure: an obvious lint error fails the build in seconds, without waiting for the long steps.

Tests in CI are run with an explicit one-shot run, not watch. vitest run executes the suite once and exits with a code by which CI judges success; a forgotten watch mode would hang the job forever. Usually this is wired into a script like test:ci, adding vitest run --coverage, so that in one pass you get both the result and coverage and do not run the suite twice for the report.

When the suite grows, sharding helps. The --shard=1/3 flag splits the tests into parts, and three parallel jobs run a third each, cutting the total time by roughly three. This is horizontal scaling of the run: the suite is the same but executes in parallel on several runners. Coverage is then gathered per shard and merged into a common report, so the split does not lose part of the data.

CI's reproducibility rests on pinning the environment. The Node version is fixed explicitly - the same as the team's and production's - and installation goes by the committed lockfile, so the machine sees exactly the same dependency versions. The package manager's store cache speeds up installation between runs without changing its result. Without this discipline 'works for me' and 'fails in CI' become the norm, and the cause is floating versions, not the code.

Run results are worth saving as artifacts. The coverage report and results in JUnit format are attached to the job so CI shows them in the interface: which tests failed, how coverage changed, where the regression is. This turns the run from a binary 'passed/failed' into diagnostics - from the artifacts you see what exactly broke, without locally reproducing the whole pipeline from scratch.