Пропустите компоненты, проверьте логику
Я исследовал варианты тестирования приложения React, экспериментировал с некоторыми доступными библиотеками и читал документацию. Тем не менее, все они, похоже, довольно кратко объясняют, к какому типу покрытия вы должны стремиться и где вы действительно получаете ценность за время, потраченное на настройку и изучение того, как тестировать.
На данный момент мне очень сложно создать вариант использования тестирования компонентов React ВООБЩЕ в приложении, которое интенсивно использует Redux для управления внутренним состоянием. Вот почему:
- Кажется, действительно сложно протестировать определенные компоненты React нетривиальными способами. Бесполезные тесты IMHO включают в себя такие вещи, как «был ли компонент смонтирован», «был ли компонент отключен», «есть ли у компонента следующие дочерние элементы» и т. Д. Почти все это вы можете определить, просто написав код и посмотрев на свой браузер. Многие низко висящие плоды могут быть достигнуты, просто используя
prop-typesв коде. - Тестирование определенных «контейнерных» компонентов, чтобы убедиться, что они содержат правильные дочерние компоненты (т.е. убедитесь, что все критические компоненты отображаются для каждого URL-маршрута) может быть полезно, но у меня никогда не было проблем в производстве, где компоненты просто не могут существовать там, где они должны быть, что не связано с CSS (плохой медиа-запрос) или с Redux (ошибочная логика редуктора не может правильно установить логическое значение).
- Потенциально полезные тесты будут проверять эффект действий (таких как нажатие кнопки), которые изменяют представление (например, добавление / удаление элемента в список). Однако, поскольку я использую Redux, у меня не так много информации о состоянии внутреннего компонента, поэтому мне кажется, что мне лучше просто протестировать код Redux. Если создатели действий Redux и функции редуктора верны, то вероятность того, что пользовательский интерфейс будет неправильным, довольно мала, поскольку я просто тупой отрисовываю состояние Redux.
- Тестирование вызовов и ответов API - еще одна полезная область тестирования. Я еще не написал никаких асинхронных тестов, но в сочетании с тестированием в магазине Redux это похоже на то место, где я получил бы наибольшую рентабельность инвестиций при тестировании. Кроме того, с помощью вызовов API я могу написать тест, зная, что мне нужно, не беспокоясь о внутреннем устройстве того, что тестируется.
- Настройка инструментов / сред тестирования - это гигантская PITA *. И накладные расходы на настройку среды псевдобраузера, чтобы я мог провести регрессионное тестирование кучи критических счастливых путей, настолько пугающие, что я даже не знаю, с чего начать.
* (Допустим, вы читаете значения конфигурации для своего кода из Webpack, теперь вы застряли, пытаясь настроить свой набор тестирования для использования конфигурации Webpack, которую он не хочет использовать, используя кучу библиотек Github с 12 звездами и последняя фиксация 13 месяцев назад.)
Временное заключение:
Тестирование компонентов с использованием Jest / Enzyme / чего угодно кажется пустой тратой времени. Подобно тому, как Typescript решает проблему, с которой я редко сталкиваюсь, прямое тестирование компонентов мало что предлагает мне с точки зрения облегчения моей жизни сегодня, а взамен обещает занять недели, пытаясь исправить и изучить от четырех до десяти различных инструментов тестирования одновременно (Jest ! Enzyme! JSDOM! Jasmine! QUnit! PhantomJS! Sinon! Karma! Tape! Selenium! Protractor! Ava!). Мне лучше просто придерживаться Mocha / Chai и покрывать 80% моих ошибок 20% кода тестирования, ориентируясь на фактическую логику в приложении.
Есть ли у кого-то другой опыт? Мне здесь что-то не хватает. Пожалуйста, оставьте комментарий, если у вас есть опыт написания тестов для компонентов React, которые не были пустой тратой времени.
Следующее, кажется, указывает на то, что я не единственный, кто ненавидит тестирование Javascript:
