Всем привет, меня зовут Александр, я являюсь фронтенд разработчиком с 4-х летним опытом работы. В этой статье я решил поделится опытом написания unit тестирования react компонентов. Плюс, хочу понастальгировать по временам, когда я учился их писать.
Начну с предистории, тесты я научился писать два года назад, но научится писать и понимать как правильно их писать это две разные вещи. Я долго не мог понять, как правильно писать, чтобы они приносили максимальную пользу и в дальнейшем их было проще сопровождать.
Для лучшего понимания вышеописанного абзаца хочу рассказать свой путь понимания, как правильно писать тесты. Когда я только научился писать эти тесты, то начал писать их как end2end тесты, сам того не понимая. Весело было, в конечном итоге получилось, что эти тесты тяжело и долго пишутся, так и их сопровождение то еще было веселье, при малейшем изменении бизнес логики необходимо переписывать половину тестов, в лучшем случае. В этот момент я понял, что необходимо компоненты дробить на более мелкие, чтобы их было проще тестировать. Также мне пришло понимание фразы, что компоненты должны тестироваться в замкнутом пространстве и на них не должно быть влияние из вне.
Едем дальше, следующий этап развития случился, когда мне указали, что я сильно мелко дроблю компоненты и так делать нельзя. В разговоре с коллегой я объяснил, что делаю это для более комфортного тестирования компонентов, на что он задал логичный вопрос: «Почему ты не мокаешь лишний функционал, который берется из вне, либо который описывается в дочерних компонентах?» . После этого вопроса он мне объяснил, как и какие компоненты нужно мокать. В результате этого разговора ко мне пришло понимание, что слишком дробить компоненты нельзя, нужно соблюдать баланс и прийти к понимаю, когда дробление излишне.
Последний этап понимания тестирования на текущий момент, который я понял совсем недавно и в дальнейшем буду его применять повсеместно — тесты нужно писать сразу после создания компонента. Я считаю, что лучше сразу написать тесты для компонента и закрыть для себя работу с ним, чем оставлять это на потом. На каком основании строится данная концепция? Допустим один раз пропустили написание тестов для компонента, второй, третий. В итоге это приводит к огромному техническому долгу , который потом необходимо наверстывать, при этом параллельно разрабатывая основной функционал. Есть еще одна весомая почему тесты необходимо писать сразу — вы знаете как работает компонент, весь контекст его работы, а значит понимаете, что конкретно нужно и в какой последовательности необходимо тестировать. Если вы оставите написание тестов на потом, например через месяц, то контекст будет потерян, а чтобы его вспомнить и понять, что нужно тестировать понадобится время, в итоге получаем потерю времени.
Алгоритм написания тестов
Теперь обсудим, каким образом писать unit тесты для react компонентов. После того, как была продумана логика компонента и выполнена ее реализация, то после этого необходимо посмотреть, что нужно тестировать? В своей практике я обращаю внимание на следующее:
- проверка текста с требованием документации проекта
- если дочерний компонент крупный, то его можно замокать и проверить, чтобы он просто отрисовался. В данном случае этого достаточно, потому что у дочернего будут свои тесты, которые покроют его функционал;
- если нужно проверить отрисовку какого-то блока html кода, то на него можно повесить id и по нему отследить отрисовку компонента;
- callback функции я тестирую очень мало, потому что в большинстве случаев этого не надо, их проверять необходимо, если они влияют на отрисовку внутри тестируемого компонента.
После того, как выделили из компонента, что необходимо тестировать, это все необходимо сразу записать в файле, чтобы не держать у себя в голове, как показывает практика - можем что-то забыть. Затем мокаем лишние дочерние компоненты и функционал, который можем повлиять из вне.
Теперь прописываем каждому отдельному тесту его логику, которую проверяем в отдельном взятом тесте.
На выходе мы получаем готовый компонент с тестами, где мы максимально охватили случаи, которые необходимо было проверить.
Вывод
В этой статье я немного понастольгировал по тем временам, когда только начал изучать тесты и внедрять их в свою практику, какие ошибки были мною допущены во время этого процесса. А вам рассказал на своем примере, что ошибаться и приходить к понимаю сути работы можно не сразу и ничего страшного в этом нет. Также вы можете взять на вооружение мой алгоритм, доработать его под себя и использовать с полным понимаем тестов.
Больше статей в моем блоге. Спасибо, что дочитали и до новых встреч в следующих статьях.
