Testy komponentów React za pomocą Vitest i Testing Library

Vitest to szybki narzędzie do wykonywania testów, stworzone specjalnie dla Vite, które będzie znajome osobom znającym Jest — ponadto doskonale współpracuje z React Testing Library przy testowaniu zachowania komponentów. Ten przewodnik omawia konfigurację, praktyczny cykl czerwono-zielony, strukturę plików oraz sposób instruowania sztucznej inteligencji do pisania kodu, aby pomagała zamiast generować błędy.

1. Konfiguracja projektu

Zainstaluj standardową ścieżkę testowania React jako zależności rozwojowe:

npm install -D vitest jsdom @testing-library/react @testing-library/jest-dom @testing-library/user-event

Dla projektu Vite React poinformuj Vitest o aplikacji w pliku vite.config.ts, aby aliasy i pluginy odpowiadały wersjom produkcyjnym:

For a Vite React project, add Vitest to vite.config.ts:

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

export default defineConfig({
  plugins: [react()],
  test: {
    environment: 'jsdom',
    setupFiles: ['./src/test/setup.ts'],
    globals: true,
  },
})

environment: 'jsdom' umożliwia korzystanie z API DOM bez rzeczywistego przeglądarki. Mały plik konfiguracyjny rejestruje matcherzy jest-dom raz dla każdego zestawu testów:

import '@testing-library/jest-dom/vitest'

Prześlij ten plik przez opcję setupFiles w Vitest, aby twierdzenia takie jak toBeInTheDocument i toHaveAccessibleName działały wszędzie.

2. Zalecany proces pracy

Użyj ścisłego cyklu: Funkcja → Test → Implementacja → Weryfikacja → Refaktoryzacja.

1. Zrozum funkcję — wymień zachowania widoczne dla użytkownika oraz ważne stany (ładowanie, sukces, błąd, pusty, wyłączony). Zaznacz granice API lub przeglądarki, które wymagają mocków, aby testy były deterministyczne.
2. Najpierw napisz test — preferuj zapytania z React Testing Library; sprawdzaj wyniki, które zauważa użytkownik, a nie prywatny stan; używaj userEvent do symulacji kliknięć i wpisywania w celu uzyskania większej realistyczności.

Zaimplementuj minimum — utrzymaj kod produkcyjny skupiony na naprawieniu nieprzechodzącego testu; unikaj elementów przeznaczonych wyłącznie do testowania lub wyciekających informacji wewnętrznych, chyba że nie ma lepszego rozwiązania.

Uruchamiaj celowe testy podczas iteracji, aby informacje zwrotne pojawiały się w ciągu sekund, a nie minut:

npx vitest run src/components/Button.test.tsx

During development:

Tryb obserwacji dla lokalnego pętli informacji zwrotnej:

npx vitest

Run the full suite

Pełny zestaw testów za pomocą skryptu npm dostępnego w twoim pliku package.json:

npm test

lub jednorazowe uruchomienie w stylu CI bez funkcji obserwacji:

npx vitest run

Check coverage when appropriate

Mierzony wskaźnik pokrycia, gdy potrzebujesz zwrócić uwagę na nietestowane gałęzie:

npx vitest run --coverage

Traktuj wskaźnik pokrycia jako wskazówkę, a nie tylko estetyczną wartość — daj pierwszeństwo sensownym twierdzeniom zamiast dążeniu do 100%.

3. Struktura testów

src/
├── components/
│   ├── LoginForm.tsx
│   └── LoginForm.test.tsx
├── hooks/
│   ├── useUser.ts
│   └── useUser.test.ts
├── pages/
│   ├── Dashboard.tsx
│   └── Dashboard.test.tsx
└── test/
    ├── setup.ts
    └── mocks/

For a component, structure tests around behavior:

Kształtuj struktury wokół wyników działania użytkownika, a nie nazw metod:

describe('LoginForm', () => {
  it('allows a user to submit valid credentials', async () => {
    // arrange
    // act
    // assert
  })

  it('shows validation errors for invalid input', async () => {
    // ...
  })  it('disables submission while logging in', async () => {
    // ...
  })
})

Zajmij się ścieżką pomyślnego działania, błędami walidacji oraz stanami wyłączenia lub ładowania w oddzielnych blokach it. Gdy coś się zepsuje, tytuł opisujący błąd powinien wskazywać konkretną zachowanie. Używaj narzędzi pomocniczych oszczędnie; klarownie sformułowana konfiguracja, która jest łatwa do zrozumienia, jest lepsza od pomysłowych rozwiązań, które ukrywają intencję.

4. Praca z agentem kodującym AI

4. Vitest-agent prompt

Poinstruuj agenta jak doświadczonego inżyniera testującego w React: najpierw napisz lub zaktualizuj nieudany test, wdroż najmniejszą możliwą zmianę, a następnie sprawdź ją za pomocą Vitest i przeprowadź kontrolę typów:

npx vitest run <target-test>
npx vitest run
npm run typecheck
npm run lint

Prosz o to, aby preferowało zapytania Testing Library (getByRole, findByText) zamiast niestabilnych selektorów CSS, aby symulowało granice sieci zamiast dostępować do stanu komponentu, oraz aby pozostawiało krótką notatkę, gdy test dokumentuje celową ograniczenie produktu.

Zwyczaje końcowe

Zachowaj konfigurację Vitest udostępnioną z Vite, aby aliasy ścieżek i pluginy odpowiadały wersji produkcyjnej. W środowisku CI preferuj funkcję run, a lokalnie obserwuj proces. Rozszerzaj zestawy testowe w miarę dodawania nowych funkcji, a nie poprzez dużą przebudowę. Dzięki temu cyklowi – najpierw test, potem implementacja, następnie weryfikacja – aplikacje React pozostają podatne na refaktoryzację, bez spowalniania szybkiego cyklu informacyjnego napędzanego przez Vite, który od początku sprawił, że Vitest stał się atrakcyjny.

Pozycje pokrewne

• Zamiana Jest na wewnętrznego exekutora testów w Node 24 — Przykład praktycznej migracji pokazuje, jak wbudowany exekutor testów w Node 24 oraz wsparcie dla TypeScript skracają czas CI, jednocześnie eliminując cztery zależności.
• Testowanie jednostkowe JavaScript z użyciem Jest i Vitest: praktyki, które się sprawdzają — Szybkie testy izolowane, co powinno znajdować się na poziomie jednostek, Vitest vs Jest vs Mocha, podejście AAA, mocki, przypadki krawędziowe, CI oraz role sztucznej inteligencji.
• Vite + React od zera, z włączonym od razu React Compiler — Budowa projektu za pomocą Vite, analiza punktu wejścia oraz włączenie React Compiler jeszcze przed dodaniem pierwszej funkcji.