Тэсты компанентаў у React з Vitest і Testing Library

Vitest — гэта быстрый тэст-раннер, створаны ў фармаце Vite, які здаецца знайомым тым, хто вжываў Jest; ён таксама гарная адпаведнасць для тэстаў повадкі компанентаў з React Testing Library. У гэтым кераванні розглядаецца налаштовванне, практычны цыкл «чырвоны-зелены», структура файлаў і спосаб прызначэння задачая ІІ-агенту для кодавання, каб той дапамагаў, а не ствараў проблемы.

1. Налаштовванне праекта

Установіце стандартны набор для тэставання React як залежнасці развітчыка:

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

Для праекта Vite React неабходна паведаміць Vitest пра аплікацыю ў файле vite.config.ts, каб аліясы і плагіны падтрымалі рэжым выпуску:

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' дае API DOM без рэальнага браузера. Невялікі файл налаштоввання рэўідуе мэчэры jest-dom адно раз для кожнага набора тэстаў:

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

Перадзейце тыя файлы праз опцыю setupFiles у Vitest, каб тэставанні на кшталт toBeInTheDocument і toHaveAccessibleName працавалі ў всіх месцах.

2. Рэкамендаваны практычны падход

Іспользуйце строгі цыкл: Функцыя → Тэст → Рэалізацыя → Перакананне → Рэфактораванне.

1. З’ясавайце сутніцу функцыі — узначыце поведанне, відныя для корыстніка, і важлівыя станы (загрузчык, успех, адказка, порожнеча, выключаны). Запісайце межы API або прыгледача, якія трэбуе моків, каб тэсты заставаліся дэтэрміністычнымі.
2. Спачатку напісце тэст — вярніцеся да запытак з бібліятэкі React Testing Library; пераканвайцеся ў рэзультатах, якія бачыць корыстнікі, а не ў прыватных станах; для рэалістычнасці выконвайце клікі і набіранне тэксту за дапамою userEvent.

Адаптавайце толькі неабяжнае — прагнучы, каб код для працы быў сфокусаваны на выкарыстоўванні для паспелення неякіх тэстаў; утрымайцеся ад вікорыстанняя толькі для тэстаў элементаў чы секрэтных дадзеных, якія могуць выйсці на волю, як толькі не існуе простыяй альтэрнатывы.

Адрабоўваце ціляваныя тэсты пад час ітэрацый, каб адзывы прыходзілі за секунды, а не за мінуты:

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

During development:

Рэжым спаглядання для локальнага цыклу адзывоў:

npx vitest

Run the full suite

Полны набор тэстаў праз скрыпт npm, які ўказаны ў вашам package.json:

npm test

альбо адзін разовы запуск у стыле CI без функцый спаглядання:

npx vitest run

Check coverage when appropriate

Аналіз паверхні пакрыцча, калі трэба звернуць увагу на неперакананыя галузі:

npx vitest run --coverage

Спрыяйце аналізу паверхні пакрыцча як карыце, а не проста як показніку — важлівейце значымыя тэсты, чым прагненне да 100%.

3. Структура тэстаў

Размешчайце тэсты разам з компанентамі, якія яны захоць:

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:

Формуйце кейсы адпраўна ўжо па рэзультатах работы карыстальніка, а не па назвах методаў:

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 () => {
    // ...
  })
})

Адбірайце окрэмыя блакі it для задавальнай сцэны, адмов у перакананні, а таксама станоў «выключана» чы скарыстання. Калі ўтвараецца проблема, заглавле з адмовай павінна называць конкрэтную дзеянне. Вядомыя функціі для аранжавання вікорыстоўвайце рэдка; чытальны дублікат настройкі лепш, чым хітрыя фіксаты, якія маскуюць намер.

4. Работа з агентам для кодавання на AI

4. Vitest-agent prompt

Інструктавайце агента як высокакваліфікованага інжынера для тэставання у React: спачатку напісце чы апдэйтуеце тэст, які не працуе, пасля чыгульна адбудавайце мінімальныя змены, а потым пераканайце іх за дапамою Vitest і праконтролюйце тыпы:

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

Практыкуйце, каб тэставальнік выбіраў запыты Testing Library (getByRole, findByText) замест нестабільных CSS-селектараў, каб імітаваць межы сеткі замест таго, каб адкрываць стан компонентаў, і каб залічваць короткую прыметку, калі тэст фіксуе намераваную абмежэння продукту.

Звычкі завершэння працы

Зберагаюце настройкі Vitest у спадзячыні з Vite, каб пазначкі шляхоў і плагіны падходзілі да рэальнай супрацоўкі. У CI выкарыстоўвайце run, а локальна — сачыце за працай. Расшырайце наборы тэстаў праз дадаванне новых функцый, а не праз масовую перэработу. За такім цыклам — спачатку тэст, потым рэалізацыя, пасля чаго перакананне — аплікацыі на React застаюцца практычныя для перэработы, не спамляючы цыклу зворачнай связі, які працюе за дапамогою Vite і ў чым заключалася прываблівасць Vitest з самага пачатку.