План курса "Тестирование в JS"

Для чего нужны тесты

Тесты нужны по нескольким причинам:

• Экономят время и средства. Позволяют не проверять руками работу кода во время разработки и после
• Могут являться спецификацией по работе функционала
• Позволяют быстро обнаружить ошибки при грядущих изменениях кода
• Имеют возможность выполняться перед деплоем для валидации работы приложения в определенном окружении

Разновидности тестов

• Статическая типизация
• Unit-тесты
• Интеграционные тесты
• Snapshot тестирование
• End-to-end тесты

Статическая типизация

• Как работает. Отлавливает ошибки и опечатки во время сборки приложения
• Может служить документацией
• Облегчает понимание кода во время чтения и ускоряет ревью
• Знакомство с TypeScript

Unit-тесты

• Как работают. Проверяют работоспособность модулей в изоляции
• Могут служить спецификациями функционала
• Атомарность тестов, параллельной запуск, изоляция
• Настройка jest в проекте
• expect и другое API
• Mock функций, модулей и зависимостей

Интеграционные тесты

• Как работают. Проверяют работоспособность двух и более модулей вместе
• Позволяют быстро обнаружить непредвиденные ошибки
• Описывают возможности интеграции модулей, демонстрируют их API

Snapshot тестирование

• Как работает. Сообщает об отличиях текущего снапшота от предыдущего
• Позволяет быстро обнаружить нежелательные и случайные изменения
• Перезапись снапшота при намеренных изменениях
• Комплиментарные тесты с expect().toMatchSnapshot()

Testing Library

Позволяет тестировать компоненты в изоляции, интеграции и даже e2e со стороны пользователя.

• Как работает. Рендерит определенный DOM-элемент и позволяет с ним взаимодействовать от лица пользователя
• @testing-library/dom, @testing-library/react и др.
• render возвращает удобное API для взаимодействия с DOM-элементом
• @testing-library/user-event. Имлементации действий пользователя
• Расширение методов expect для большей декларативности и чистоты тестов

End-to-end

• Как работает. Имитирует взаимодействие пользователя с приложением в браузере
• Регрессионное тестирование и его автоматизация
• Знакомство с Cypress
• Чаще всего написанием e2e тестов занимаются QA-автоматизаторы

Что тестировать, когда и как?

На бизнес-логику, утилиты и форматтеры стоит писать unit-тесты, чтобы быть уверенным в том, что они верно работают в изоляции. На взаимодействие ключевого функционала стоит писать интеграционные тесты, которые отловят, если что-то будет некорректно работать друг с другом после изменений. Чтобы не проводить мануально регрессионные тестирования всего приложения целиком, лучше поддерживать end-to-end тесты. В некоторых случаях большую пользу может принести snapshot тестирование. Его использование может защитить модули от нежелательных изменений.

Избирать подход в зависимости от толерантности приложения к наличию возможных ошибок, количества затрачиваемого времени на ручные проверки написанного кода, количества коммитов и вовлеченных разработчиков. В конце концов, для некоторых приложений ручное тестирование может быть даже выгодней.

Покрытие кода (Code Coverage) - процент кода, который выполняется при выполнении тестов. Не нужно добиваться 100% покрытия кода и тестировать проверенный функционал библиотек. Многие библиотеки имеют 100% покрытие кода тестами, потому что их код исходит от большего количества разрабочиков. Покрытие тестами позволяет отследить опечатки, ошибки и нежелательные последствия. Однако покрытие кода тестами не означает, что тесты написаны без упущений и покрывают всё возможные кейсы использования библиотеки.

Бонус: Методология TDD

Test-Driven-Development (TDD) часто может сэкономить время на ручных проверках работоспособности кода, позволит определить понятную спецификацию выполнения задачи. Чем раньше написан тест, тем больше выгоды он принесет.