О пользе (или её отсутствии) тестирования Реакт-компонентов

Наткнулся на очередную статью о юнит-тестировании Реакт-компонентов. К сожалению, в таких статьях часто призывают бросать всё и начинать тестировать компоненты, но редко объясняют, зачем и кому это нужно. Попробую восполнить этот пробел.

Можно разделить тестирование компонентов на два вида: снепшотное тестирование разметки компонентов и тестирование логики компонентов.

Снепшотное тестирование комопнентов

Снепшотное тестирование разметки компонентов — довольно бесполезная вещь в подавляющем большинстве случаев. Оно полезно, если вы разрабатываете общую библиотеку компонентов в крупной компании вроде Яндекса или Авито. А если вы продуктовый разработчик, такие тесты себя не окупят — они слишком низкоуровневые. Они отслеживают только изменения разметки компонентов, а по одному только диффу разметки скорее всего будет сложно сказать, поломается ли компонент в браузере пользователя.

Интерфейс меняется чаще логики, поэтому если у вас есть свободное время, в первую очередь покройте тестами логику приложения. Если вы покрыли логику тестами и у вас всё ещё остаётся свободное время, прикрутите тестирование скриншотами — оно гораздо полезнее снепшотов, потому что вместо снимков разметки делаются снимки отрендеренного компонента с учётом особенностей окружения (браузера).

Тестирование логики компонентов

Этот вид тестирования полезен в случаях, когда у вас есть компоненты со встроенной логикой: например, выпадающие списки, саджесты или таблицы с сортировкой. Но я бы всё равно посоветовал вынести логику наружу компонента, написать на неё обычные юнит-тесты, а корректность работы интерфейса проверять автотестами и скриншотами — это надёжнее простых снимков разметки.