Тестування кліентських додатків розробниками

Ця стаття описує тестування кліентських додатків безпосередньо розробниками FE команди. Вони запускаються перед мерджем будь-якої зміни у гілку.

Технології та типи тестування

jest - ранер тестів який використовується для запуску всіх кліентських тестів
enzyme - бібліотека для тестування React-додатків. Використовується для unit тестів завдяки можливості shallow рендера компонентів. Недоліком є неможливість виклика react-hooks.
@testing-library/react - бібліотека для тестування React-додатків. Використовується для integration тестів завдяки можливості зручно управляти діями користувача. Не може ефективно застосовуватися для unit тестів бо не має функціоналу shallow рендера.

Підхід до тестування

Основні положення та ціль

Ціль - максимізувати покриття React компонентів саме integration тестами у відповідність до сучасного консенсусу у React community та неможливості покриття сучасних React компонентів з хуками використувуючи enzyme.

Приоритет при тестуванні компонентів необхідно надавати тестуванню цілих сторінок з релевантними сценаріями які використовує бізнес.

Проводиться тестування усіх пакетів (packages/*)

Coverage

Тестами покривається уся бізнес логіка включаючи React компоненти, а також та логіка що відноситься до redux тобто шару даних. Виключенням є шар api, файли css-стилів та інші файли які по суті не мають власної логіки (з виключеннями можно ознайомитись у файлі sonar-project.properties).

Ціль - мати покриття більше 80% для відповідних файлів.

Розташування файлів з тестами

Усі тести пишуться окремо від продакшен коду. Файли з тестами та пов’язаним кодом слід розташовувати поруч з файлами які тестуються у папці __tests__.

Файли повинні мати назву:

File_under_test.test.tsx - unit тестування React компонентів з використанням enzyme (e.g. Button.test.tsx);
File_under_test.int.test.tsx - integration тестування React компонентів з використанням testing-library (e.g. TaskPage.int.test.tsx);
File_under_test.int.ts - тестування інших файлів (e.g. operations.test.ts);

Розробка

packages/web-components

Пакет бібліотеки не використовує craco для запуску тестів та є незалежним від інших пакетів. Тому записк тестів необхідно викновати через команду jest напряму. Приклад запуску одиночного теста з вибором ранера у WebStorm:

Для integration тестів необхідно використовувати утіліти написані для web-components з ціллю включити найпоширенеші провайдери:

import { render } from '#web-components/utils/testUtils';

it('should test', () => {
    render(<Component />);

    /*rest*/
});

Інші пакети

Усі пакети окрім web-components використовують craco для запуску тестів (без craco білд для тестів не зможе знайти необхідні файли у інших пакетах). Приклад запуску одиночного теста з вибором ранера у WebStorm:

Для integration тестів необхідно використовувати утіліти написані у пакеті shared з ціллю включити найпоширенеші провайдери:

import { render } from '#shared/utils/portalTesting';

it('should test', () => {
    render(<Component />);

    /*rest*/
});