Как стать автором
Обновить

Что необходимо учитывать при юнит-тестировании фронтенда

Время на прочтение 5 мин
Количество просмотров 5K
Всего голосов 10: ↑7 и ↓3 +4
Комментарии 6

Комментарии 6

80 проентов — это как средняя температура по больнице. Где-то проверили каждый тривиальный метод, а где-то не протестировали функцию со сложной логикой. А в среднем покрытие даже выросло.

НЛО прилетело и опубликовало эту надпись здесь
В прошлом проекте пеклись о юнит тестах и покрытии кода. В результате была уверенность что отступ будет 10рх и никакой уверенности что компонент в целом работает.

Без конкретных сложных примеров это статья ни о чем. Например селект с фильтрацией и мультиселектом или дейтпикер.

UI компоненты очень плохо тестируются юнит тестами, чем сложнее компонент тем меньше толка в юнит тестах. Неизбежно есть сайд эффекты и тестовая среда работает не так как браузер, плюс асинхронные фичи. Моки только делают ситуацию хуже.

Разумней иметь переиспользуемые маленькие чистые функции для любых целей, тестировать их на 100% юнит тестами. А более сложные компоненты тестировать e2e тестами.

Стремление к слепому 100% покрытию тестами не заменит продуманой архитектуры и рефакторинга. Но большое количество юнит тестов осложняет этот процесс.
Статья интересная, схожие с моими наблюдения. Организовать порядок выполнения тестов хорошая идея.

Юнит тесты тоже полезны, для маленьких чистых функций. Но большую часть времени е2е тесты(или интеграционные) дают уверенность что фича работает и не мешают рефакторить.

А подход писать юнит тесты на каждый чих в погоне за покрытием это маразм. Приводит к тому тесты становятся ритуалом, их пишут и исправляют абсолютно бездумно. Покрытие дает ложное ощущение что код хороший, хотя может быть неподдерживаемая лапша.
Потом это бездумное отношение перекидывается на код и начинается ад.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий