🛡 Как и зачем писать тесты Как и многие разработчики, в начале своего обучения я забивал на написание тестов. Сейчас я расскажу, когда нужны тесты, и что именно тебе нужно тестировать как фронтендеру. Когда я только пришёл в OZON, первая крупная задача, которую мне поставили — это повысить стабильность в приложении. Проект так разросся, что изменения в одном месте ломали реализацию в другом. За 3 года мы достигли покрытия в ~70%, написали ~5000 юнит тестов и ~100 e2e тестов. Не помню когда последний раз откатывал прод или находил серьёзный баг в реализации, если честно. Точно не в этом и не в прошлом году 😂 👉🏻 с чего начать Читаем статью от Кент Доддса, чтобы понять базу тестирования. На собеседовании очень любят спрашивать про типы тестов, про пирамиду. Читаешь за 6 минут и закрываешь этот пробел. От него же есть хороший курс Testing JavaScript Потом можно глянуть два мастер-класса от Ильи Климова: по тестированию базы и вью приложений 👉🏻 когда можно НЕ писать тесты Делаем простенький сайт, лендинг, где нет критичной логики. Разрабатываем MVP и важно как можно быстрее выкатить приложение. 👉🏻 какие тесты писать На компоненты и утилиты обычно пишутся юниты или интеграционные, на страницу целиком e2e. Можно сделать ещё скриншотные, если есть сторибук и высокие требования к дизайну. 👉🏻 на чём писать Юниты пишем на Jest или на Vitest, если проект работает на Vite. Для e2e лучше всего будет Playwright. 👉🏻 что тестировать Тестируется то, что публично. А это итоговый HTML — правильный тэг, правильная структура. Это эмиты событий во вью или пропс функции в реакте. Это различные походы в бэкенд, который нужно будет подменять. 👉🏻 как тестировать Передаём пропсы для изменения состояния. Вызываем события на компоненте, чтобы посмотреть на поведение. Изменяем внешние зависимости, например, стейт менеджер. 👉🏻 категорически запрещено Вызывать функции внутри компонента по имени напрямую. Изменять локальный стейт компонента напрямую. 👇🏻 распространённые ошибки Тест хрупкий. При изменении внутренний реализации компонента — тест, в идеале, не должен падать. Тест нечестный. Тест должен падать только тогда, когда проблема внутри этого компонента. И ПОМНИ Когда пишешь тест, представляй себя пользователем, а не разработчиком. ❌ ты не знаешь, что внутри компонента ❌ ты не знаешь детали реализации У тебя есть только вёрстка в браузере и ты можешь этот компонент тыкать ручками. Ставь ❤‍🔥, если пойдёшь внедрять) #useful@webistomin_channel ——— 🧑 • телеграм • ютуб • задать вопрос