---
title: "Vitest, component tests, Playwright, and visual confidence"
chapter: "17"
---

# Vitest, component tests, Playwright, and visual confidence

New Angular CLI projects use Vitest and jsdom by default. Real browser tests
remain essential for layout, accessibility, and platform behavior.

## Test pyramid by evidence

- pure tests: transformations and domain rules;
- service/store tests: workflows and state transitions;
- component tests: template semantics and user interaction;
- HTTP tests: request contract and failure mapping;
- browser tests: routing, auth, focus, responsive behavior, hydration;
- visual checks: deliberate appearance regressions.

## Vitest and TestBed

Use TestBed when Angular injection, templates, or lifecycle are the subject.
Use plain Vitest for ordinary TypeScript. Query by accessible roles, labels, and
visible outcomes rather than CSS implementation classes.

## HTTP testing

Provide HttpClient before `provideHttpClientTesting`, expect exact requests,
flush success and failures, and verify no unexpected requests remain.

## Browser mode and Playwright

Angular's test runner can use browser providers. Playwright E2E covers Chromium,
Firefox, and WebKit. Test keyboard use, mobile drawers, focus restoration,
deep links, offline/errors, and real server responses.

## Flowbite components

Test one initialization per element, destroy cleanup, open/close synchronization,
escape/backdrop behavior, focus trap, route transitions, and SSR browser guards.

## Avoid brittle tests

Do not assert hundreds of Tailwind class tokens unless the utility is the
contract. Prefer semantic outcome and a small number of intentional visual
snapshots.

## Feynman check

A unit test proves code. A component test proves Angular rendering. A browser
test proves the platform interaction. A visual test proves selected pixels.