Комментарии 23
А потом меняются бизнес требование, начинается изменение функционала и все тесты и потраченное на них время псу под хвост.
Более того, юнит тесты дают ровно 0% гарантий что проект реально работает и не сломался, это фронтенд, тут всё со всем связано и очень много сайд эффектов. Нажатие кнопочки в одном месте может очень сильно изменить поведение во многих других местах в рамках бизнес логики.
Отсюда вывод - зачем тратить время в пустоту? Когда вместо этого можно делать куда более полезные вещи.
Когда вместо этого можно делать куда более полезные вещи.
А что конкретно имеете в виду?
Более того, юнит тесты дают ровно 0% гарантий что проект реально работает и не сломался
Потому что они не для этого)
Зато упавший юнит говорит, что что-то сломалось :)
А что конкретно имеете в виду?
Полезные вещи вместо бессмысленных юнит-тестов фронта - новые фичи, новые проекты и т.п. Время - ресурс не возобновляемый и его нельзя купить, тратить его на бессмысленные юниты для фронт приложения это нелепость. Я могу понять тесты для библиотек, это да, must have. Но вот именно для фронтового проекта это просто время в пустоту.
Потому что они не для этого)Зато упавший юнит говорит, что что-то сломалось :)
Кто сказал что что-то сломалось? Бизнес логика изменилась и всё, тест упал, с чего вы взяли что что-то сломалось, наоборот работает так, как задумано, это просто бестолковый тест сломался и не более.
Бизнес логика изменилась и всё, тест упал, с чего вы взяли что что-то сломалось, наоборот работает так, как задумано, это просто бестолковый тест сломался и не более.
А с чего вы взяли что бизнес логика изменилась? Кто то поменял что то в компоненте просто.
Но вот именно для фронтового проекта это просто время в пустоту
В вашем мире чем отличается компонент из библиотеки и компонент из фронтового проекта?
Я вот пишу юниты для компонентов во фронтовом приложении и часто они помогают отловить ошибки при внесении изменений.
А с чего вы взяли что бизнес логика изменилась? Кто то поменял что то в компоненте просто
Ну во первых что-бы что сломать, это надо конкретно постараться и вообще не понимать что ты делаешь. Во вторых как показывает практика, 19 из 20 изменений в компонентах происходят именно из-за изменения бизнес логики, и они должны после этого работать либо по другому, либо их функционал расширяется, а не просто так с целью их сломать.
В вашем мире чем отличается компонент из библиотеки и компонент из фронтового проекта?
Тем, что компонент из библиотеки не меняется в процессе жизненного цикла проекта.
Я вот пишу юниты для компонентов во фронтовом приложении и часто они помогают отловить ошибки при внесении изменений.
Значит вы их ломаете часто, а значит не понимаете что делаете, когда изменяете их)
В его мире время тратить стоит только на изучение mobx
Соглашусь, починка тестов может занять некоторое время + все 100% тестами не покроешь.
Однако, львиная доля пользы от юнит-тестирования приходится на TDD, то есть написание тестов до реализации. Не зря говорят: "Хороший код – тестируемый код".
Как тестировать фронтенд, кратко:
Не пишем бизнес логику внутри представлений
Вообще никогда не пишем бизнес логику внутри представлений
Совсем никогда не пишем бизнес логику внутри представлений
Пишем юнит-тесты на бизнес логику
Если вам всё ещё хочется писать тесты на фронтенд, возможно вам нужно тестирование скриншотами
P.S. Исключения могут составлять общие компоненты со сложной собственной UI логикой. Например, самописный tooltip.
Да, в целом юнит-тесты стоит писать на сложную разветвленную бизнес-логику, например, в библиотеках.
Пишем юнит-тесты на бизнес логику
Во фронте почти не бывает бизнес-логики. Разве сам фронт и является продуктом - игра, онлайн-фотошоп, етс.
Вполне себе зависит от терминологии. Показать контрол выбора паспорта и сделать его обязательным, если возраст больше 14 - вполне себе бизнес логика
Смотря что это за приложение и что именно считать бизнес логикой. Например, сложный wizard, экраны и поля которого динамически определяются на основе данных на клиенте и который должен породить некую бизнес сущность.
Показать третий шаг формы, вместо второго, на основе поля ввода в первом шаге;
динамическая смена валидации полей на основе других полей и тд. - это всё логика UI конкретно этого клиента (фронта).
Настоящие бизнес-правила (источник истины) - находятся вне браузера, на бекенде, в схеме бд если угодно. Конечно же если мы говорим про распределённые системы, а не бекенд-лесс-браузерные инструменты (игры, редакторы, и т.д.).
Внутри фронта может быть сколь угодно много форм, и их связей, порядок показа попапов, т.е. фронт может быть большим и очень большим с накрученной ui логикой, но процессы обычно простые:
отреагировать на действия юзера по каким-то ui-правилам
отправить этот результат действия на бек
там произойдёт настоящее бизнес-правило и валидация
отправить результат назад на фронт, отреагировать на это по каким-то ui-правилам
Чушь полнейшая. Таким подходом можно сказать что на бэке нету никакой бизнес логики. Ведь это всего лишь хранилка данных. На данные, отдай эти. Какая тут бизнес логика?)
На беке будет бизнес-логика - "не выдавать кредит лицам младше 18 лет" (т.е. тут по настоящему нужно проверять, вдруг запросы курлом приходят).
На фронте будет ui-правило - "не показывать следующий шаг формы, если на первом шаге поле возраст меньше 18 лет" (т.е. тут сугубо фронтовая история, именно этого фронта, в мобильном приложении всё может быть оформленно по другому).
UI-правилами на каждом конкретном фронте - могут крутить и вертеть как угодно в зависимости от ux! Мой поинт в том, что фронт может меняться быстро и часто, и неправильно говорить что во фронте есть бизнес-логика (несмотря на то что иногда есть дублирование правил валидации как на клиенте так и на беке - но это разные валидации).. просто кому-то хочется добавить важности обычной "вьюхе" в терминах MVC.
Меня прямо иногда удивляет безапелляционность подобных заявлений.
Чем по вашему глобально отличается компонент реакта от любой другой функции? Я с таким же успехом могу и домены построить на компонентах, и бизнес логика там будет уместна.
Можете.
Бля меня глобально отличается тем, что это view-компонент конкретной библиотеки представления.
Если вы пишите бизнес логику (возьмём пример с контролом паспорта выше) в таком компоненте, а потом тестируете его, то, по факту, вы пишите интеграционный тест, ведь нужно ещё эмулировать виртуальный дом, работу рантайма реактуа и тд и всё это ради чего? Чтобы проверить разметку при двух вариантах if? Вы реально сомневаетесь в способностях реакта к условному рендерингу?
Но вот код, который генерирует тот самый bool для контрола на основе входящих данных протестить хочется, но как это сделать, не делая тест на компонент реакта? Вынести логику и использовать её как сторонний сервис по отношению к компоненту.
В этом случае код автоматически разделяется по слоям, представление зависит от логики, а мы получаем маленький и простой тест.
засучить рукава и начать прокликивать UI вручную
Наиболее оптимальный способ для бизнеса, и как ни странно для DX программиста (чтоб не выгорел от бесполезности бытия).
На месте руководителя - я бы запретил юнит-тесты на фронте, и нанял бы пару qa-мануальщиков на этапе активной разработки.
После оживления проекта, т.е. выкатки в прод и хоть какой-то генерации прибыли - добавил бы пару синьйоров на e2e и интеграционные тесты. С покрытием только багов, которые реально встретились в проде.
Юнит-тесты на фронте - прожигание ресурсов как человеческих, так и машинных. UI может меняться слишком быстро, чтобы писать на него тесты. Только если ваш продукт и есть сам UI - тогда ок, можно даже тестирование скриншотами добавить.
выстраивания четких границ между логикой и UI
Делать религию и городить абстракции между "логикой" и UI внутри фронта - также оверхед. Фронт - это всего-лишь view-слой всего MVC-приложения. Этот слой может меняться быстро и часто. Настоящая бизнес-логика\транзакции вот это всё - вне браузера. Внутри фронта - может быть сколько угодно сложная ui-ая логика, но это всего-лишь view-слой системы вцелом.
Да, ставить юнит-тесты во главу угла действительно не стоит. Однако, через них можно выявить некоторые изъяны в приложении, например, проблемы с расширяемостью компонентов.
Так сказать, взглянуть со стороны на свой код через призму тестов:)
Какая-то особая расширяемость компонентов, разве только если это не какая-то библиотека общих ui элементов, в продуктовом проекте практически всегда идет по грани нарушения принципа yagni.
Если проект не мертвый на поддержке, то он активно развивается, вводятся новые фичи, удаляются неудачные фичи, зачастую возможны редизайны (в том числе серьезные, а не просто цвет да шрифт поменялись немного), версии для мобилок, таблета, десктопа могут различаться не только стилями, но и вообще поведением и логикой взаимодействия компонентов между собой. Зачастую, вместо того, чтобы городить абстракцию над абстракцией ради абстракции и пробовать строить расширяемость ради расширяемости, лучше добавить обычный параметр компоненту или вообще скопипастить общую часть, все равно потом делить по чанкам и лишнего не загрузится, если оно не нужно.
Если все постоянно покрывать тестами - то в итоге получится написание тестов ради самих тестов, которые еще и придется часто переделывать, при этом увеличивая time-to-market.
Если для каких-либо чисто утилитарных функций еще можно понять, все же это редко меняется в проекте, то для вью слоя это бесполезная трата времени.
Оправдать написание тестов на вью можно разве что если хочется дать задачу для начинающего, чтобы человек разобрался с этой темой, для общего кругозора, понимания и галочки в резюме.
Интересно наблюдать как разработчики кидают тапками автоматизаторов на UI, мол вы бесполезным делом занимаетесь. Я уже давно понял что разработчиков вообще бы устраивало бы если всё взаимодействие с приложением происходило в терминале, такой хардкор, который возвращает нас лет на 30 назад. Но спрос есть именно на приложения с UI оболочкой, причем к которому предъявляется тоже свои стандарты уже. Например, поле для ввода телефона можно вводит именно цифры, а не буквы и причем именно в кол-ве равным номеру телефона. И без тестирования UI никуда не деться. И 2 ручных тестировщика ни как не справятся. Разработчикам бы стоило сначала поинтересоваться какое кол-во тестов на UI у ручных тестировщиков и попробовать их все пройти после каждого релиза. А потом утверждать что пытать их автоматизировать пустая трата времени. И кстати в последние годы мы практически не встречаем приложений с поехавшим UI и не обосновано не работающими полями и кнопками.
Зачем писать юнит-тесты на фронтенд?