Javascript тестирование – теория
Для чего нужно тестирование?
Цель тестирования не в том, чтобы просто проверить, как работает функция или компонент (это и вручную можно “потыкать”), а чтобы описать сценарий для работы этой функции. И если придет кто-то другой и из-за изменений кода этот сценарий нарушится, то тест об этом сообщит.
Цель тестирования – проверка соответствия ПО предъявляемым требованиям.
Регрессионное тестирование – проверка системы после каких-то изменений, и проверка не нового функционала, а убеждение в том, что не сломался старый.
Типы тестирования
Демонстрация тестов в форме пирамиды означает, что UNIT тестов должно быть максимально много, а E2E (“end to end”) максимально мало. Это грубо говоря пропорция количества тестов, которые надо писать.
UNIT тесты пишутся на отдельные маленькие части системы (модули). Под модулями имеются в виду функции, хелперы, методы какого-то класса, компонент для предоставления UI.
Скриншотные тесты делает система, которая снимает скриншоты с UI и сравнивает их с более старыми путем накладывания одного на другой. Потом она показывает эти изменения, чтобы подтвердить их. В случае подтверждения старые скриншоты заменяются на новые. Так можно выявить, например, что изменился шрифт, там где он не должен был меняться.
Интеграционные тесты (интеграционные) применятся для тестирования чего-то в связке, т.е. нескольких модулей. Например, несколько компонентов в связке, несколько классов, пересекающихся друг с другом как-то.
E2E тесты (End-to-end) – это тесты, которые на реальных данных, с реальным бекендом в браузере сам нажимает на кнопки, сам отправляет какие-то данные. Эти тесты предназначены для проверки какой-то ключевой функциональности, например, авторизацию, регистрацию, удаление пользователей, оплату, создание каких-то сущностей, т.е. важный функционал.
Примерные теоретические пропорции (сколько каких тестов надо писать):
- E2E – 10%. Их писать дольше, тяжело поддерживать, долго выполнять (лучше запускать на удаленном сервере), поэтому они и пишутся только на ключевой функционал.
- INTEGRATION – 20-30%. Они чуть легче в поддержке, но траты на их написание все равно достаточно большие.
- Скриншотные + Unit – 70-80%. В идеале практически весь функционал, который можно вынести в модуль, нужно тестировать.
Пример стека технологий для тестирования
Главный принцип UNIT тестирования (как правильно подбирать данные для тестирования)
Существует так называемый “квадрат данных” или “квадрат тестирования” (название неточное). Основная его суть в том, что значения, попадающие в центр этого квадрата, считаются валидными (правильными). Т.е. модуль должен давать корректный результат, если входные данные соответствуют центру этого квадрата.
Поэтому:
- Один тест-кейс всегда пишем, чтобы данные были внутри квадрата.
- Второй тест-кейс всегда пишем на пограничные значения (корнер-кейсы), чтобы убедиться, что на границах функция также возвращает корректный результат.
- Пишем тест для проверки невалидных данных. Т.е. берем значения больше валидного, меньше валидного… В отношении квадрата это право, лево, верх, низ.
Видео, с которого взят материал: