Комментарии 6
80 проентов — это как средняя температура по больнице. Где-то проверили каждый тривиальный метод, а где-то не протестировали функцию со сложной логикой. А в среднем покрытие даже выросло.
0
НЛО прилетело и опубликовало эту надпись здесь
В прошлом проекте пеклись о юнит тестах и покрытии кода. В результате была уверенность что отступ будет 10рх и никакой уверенности что компонент в целом работает.
Без конкретных сложных примеров это статья ни о чем. Например селект с фильтрацией и мультиселектом или дейтпикер.
UI компоненты очень плохо тестируются юнит тестами, чем сложнее компонент тем меньше толка в юнит тестах. Неизбежно есть сайд эффекты и тестовая среда работает не так как браузер, плюс асинхронные фичи. Моки только делают ситуацию хуже.
Разумней иметь переиспользуемые маленькие чистые функции для любых целей, тестировать их на 100% юнит тестами. А более сложные компоненты тестировать e2e тестами.
Стремление к слепому 100% покрытию тестами не заменит продуманой архитектуры и рефакторинга. Но большое количество юнит тестов осложняет этот процесс.
Без конкретных сложных примеров это статья ни о чем. Например селект с фильтрацией и мультиселектом или дейтпикер.
UI компоненты очень плохо тестируются юнит тестами, чем сложнее компонент тем меньше толка в юнит тестах. Неизбежно есть сайд эффекты и тестовая среда работает не так как браузер, плюс асинхронные фичи. Моки только делают ситуацию хуже.
Разумней иметь переиспользуемые маленькие чистые функции для любых целей, тестировать их на 100% юнит тестами. А более сложные компоненты тестировать e2e тестами.
Стремление к слепому 100% покрытию тестами не заменит продуманой архитектуры и рефакторинга. Но большое количество юнит тестов осложняет этот процесс.
0
Ни те, ни другие лучше не писать.
https://habr.com/ru/post/510824/
0
Статья интересная, схожие с моими наблюдения. Организовать порядок выполнения тестов хорошая идея.
Юнит тесты тоже полезны, для маленьких чистых функций. Но большую часть времени е2е тесты(или интеграционные) дают уверенность что фича работает и не мешают рефакторить.
А подход писать юнит тесты на каждый чих в погоне за покрытием это маразм. Приводит к тому тесты становятся ритуалом, их пишут и исправляют абсолютно бездумно. Покрытие дает ложное ощущение что код хороший, хотя может быть неподдерживаемая лапша.
Потом это бездумное отношение перекидывается на код и начинается ад.
Юнит тесты тоже полезны, для маленьких чистых функций. Но большую часть времени е2е тесты(или интеграционные) дают уверенность что фича работает и не мешают рефакторить.
А подход писать юнит тесты на каждый чих в погоне за покрытием это маразм. Приводит к тому тесты становятся ритуалом, их пишут и исправляют абсолютно бездумно. Покрытие дает ложное ощущение что код хороший, хотя может быть неподдерживаемая лапша.
Потом это бездумное отношение перекидывается на код и начинается ад.
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Что необходимо учитывать при юнит-тестировании фронтенда