Я долгое время был антогонистом тестированиям. Вот просто мог на вас с кулаками полезть, если бы вы мне предложили UI тестировать. UI это то что чаще всего меняется в приложении. Особенно в молодом продукте. Будьте готовы переписать ваш продукт раза 3-и за первый год. И еще несколько раз за последующий. Возможно к третьему году он приобретет финальные очертания.
Но както один мой друг показал, что и как можно решить тестами, и какая у них великая польза. И увдинного не развидеть.
По дефолту во все свои проекты я добавляю тесты на Jest. Очень круто, очень удобно, особенно радует zero config фича. А так же то, что вы можете решить практически все свои потребности в тестах имея только эту либу. Под капотом, там старый добрый Jasmine. Можно запускать тесты отдельным демоном в редакторе и прям кайф.
Но зачем нам на фронте тесты? Смотрите друзья. Мы можем решить ряд типовых задач, без необходимости открывать браузер или запускать код. По сути, вы проводите большую часть времени в редакторе. На основе задачи, или бизнес логики вы накидываете, какие нибудь простенькие тестики. Пишите код, сразу в консольке можно чекнуть его работу. Без каких либо сэндбоксов, или необходимости, запускать все приложение.
А это ведет к невероятной продуктивности. Разрабатывать таким образом фрэймворкозависимый код это полный ад. Так, что из плюсов, мы начинаем стремиться к тому, что бы минимизировать такие зависимости, упростить функции, сделать их более атормаными. И все происходит самим собой. Код которым вы не должны гордиться, становиться достаточно хорошим, что бы в туже секунду улететь в продакшн.
Ладно это не та цель ради которой стоит использовать тесты на фронте. Та цель, уменьшить запуск бразуер, если отойти в сторону, каждый раз когда вы переключаетесь с редактора на браузер, вы переключаете внимание, вы теряете время. А время ценный ресурс. Вы можете даже психологически устать, если будете прыгать туда сюда. И никакой HMR, SSR вам не поможет.
А вот тесты помогают. Вы стачало прописываете всю бизнес логику тестируете ее тестами, продумываете флоу с данными, адаптеры. Все это можно отладить без браузера. И в конце вы просто подключаете эту логику к вьюхе или компонену, привязываете юзерские клики и действия. И уже доводите до ума в браузере.
Как результат, у вас есть опорные тесты, которыми вы гоняли бизнес логику, и они вам еще пригодяться, когда вам надо будет ее поправить или усложнить.
Старнно но я эту бибилотеку незамечал долгое время, открыл ее буквально полгода назад. Незнаю это пушка. Станно но практически нигде ее не используют. Да я разработчиков которые ей пользуются могу пересчитать на одном пальце руки. Но либа очень мошьная.
Что же такое она делает?
"Wallaby.js runs your JavaScript tests immediately as you type and displays execution results in your code editor. It also provides beautiful test and code coverage reports updated in realtime." - собствено это она и делает.
Зачем она нам? Что бы отлавливать ошибки кода на этапе написания кода, просто быстро без дополнительного бадхеда. Отлично работает в свзязке с тем же Jest. Вас же менеджеры скорее всего замотивировали писать на typescript отлавливания ошибок на этапе сборки, так вот wallaby.js позволяет отлавливать ошибки еще раньше. Конечно надо писать тесты для этого, но и типы, сами себя не пишут.
Из минусов, будьте готовы к тому, что первый запуск приложения у вас будет долгий, так как демон wallaby, прогонит все тесты до начала работы с проектом. Больше тестов, дольше первый прогон. Сильнее будет напрягаться ваш CPU.
Я немножко написал про логику в начале этой главы. Решил еще раз обратить на это внимание. Бизнес логика должна быть фрэймворко независимой на столько на сколько это возможно. Макисмальна покрыта тестами. Это важно. Видите, я даже болждом подчеркнул важность.
Почему?
Я заметил что ни, что так не развивается в приложении как бизнес логика, новые фичи, эволюция старых фичей. Через месяц ты возвращаешься к своему старому коду, и боишься его править, потому что надо сесть и вспомнить а почему это написанно таким образом. А нафига вот тут этот код.
Хух, попробую описать по простому - бизнесл логика - это та часть приложения, которая не поддается здарвому смыслу, ее невозможно понять и запомнить. Она просто есть, именно такая, какая нужна бизнесу в данный момент времени.
Исходя из понятия бизнес логики, покртие ее тестами, позволяет нам экономить тонну времени при внедрении новых фич, или изменении старых. А так же избегать дурациких багов, когда ты просто забыл какой либо дурацкий кейс.
Да, но именно в сравнении одних картинок другим, на одной и тойже OS. Это позволяет избежать дурацких моментов, когда ты случайно удалил какую либо кнопку, или поплыла верстка.
Само собой не нужно стараться затестировать таким образом все страницы, какой смысл? Только проблемные места. Например нормально отображение при различных оринетациях бразуреа, различных расширениях. При разных темах.
Вот пример такой либы на всякий
Не нужно. Если заставляют, просто сабатируйте все что можно. Это лишино какого либо здравого смысла. Просто компания хочет съэкономить деньги на тестировщиках.
Смотрите, зачастую ну никто не хочет писать доку и расписывать что либо. Вот поэтому на проектах ну не существует нормальной документации. Хорошо если задачи не падают в архив и удаляются, и можно посмотреть на задачи сделанные пару лет назад. Почитать и разобраться что к чему. Часто и такого нету.
Вот, вот а когда доку пишут под кнутом. Мол ребята, надо все описывать, это часть вашей работы, это то за что мы вам платим. Льют в уши нерадивые управленцы. В таком случае мы имем кусок нечитабельного говна. На которое лучше даже не смотреть. Потому что такая дока или вики - превращается рано или поздно в помойку.
Понимаете, описывать задачу в тексте, это искуство, с которым зачатсую и супер куртые BA не справляются. Даже написать песню изучив основы рифмы или 4 х стопный ямб покажется вам адом, если у вас к этому душа не лежит.
Все на что мы можем опираться в дальнейшем - это хлебные крошки что мы сами себе оставили. Это тесты. По тестами легко проследить фичи, понять логику, это практически язык документации понятный любому программисту.
Это еще один повод писать тесты.