Всем привет!

Сегодня хотел бы поговорить про тесты и то, как можно начать их писать (обычно самая большая проблема).

Для тех, кто не в курсе, зачастую большинство фронтенд проектов вообще не имеют ни одного теста.

Говорить о том, хорошо это или нет сейчас не буду. Давай больше сфокусируемся на том, как же все-таки начать их писать.

Собственно, тут могу дать 2 простых совета:

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

Я думаю, что первый метод один из самых лучших, так как тут закрывается сразу несколько аспектов:

- У вас уже есть готовый код и понимание того, что в нем нужно проверить.
- Легче объяснить продуктам, почему нужно потратить доп время на написание тестов. Виден четкий профит.
- Можно понять, как нужно писать код, чтобы его было проще тестировать (будет очень полезно в будущем).

После нескольких подобных сессий вы будете уже намного лучше понимать, как тестировать ваш код. Затем уже можно переходить и к новым фичам.

Порядка этого придерживаться не обязательно, так как у вас на проекте из старого кода может быть только легаси 5 летней давности.

Касательно типа, я бы советовал начинать с unit тестов, так как они самые простые.

E2E и интеграционные можно добавить потом, когда уже наберетесь опыта и будет понимание того, что именно нужно покрыть такими тестами.

Стоит так же обращать внимание на то, чтобы ваши тесты как можно меньше были завязаны на имплементацию.

В случае с фронтом, например, стоит тестировать через пользовательские взаимодействия и не завязываться на пропсы, стейт и тд.

По этой теме писать можно очень много, но, как и со всем в жизни, самое главное и сложное - это просто начать.

Всем хорошего вечера!

#devtips #testing

Всем привет, друзья!

Сегодня хотел бы поделиться своими мыслями касательно ручного тестирования перед выкаткой на прод, и почему я считаю, что его нужно обязательно проводить в каком-то виде.

Небольшая предыстория, на 2-х последний работах у нас не было ручного тестирования вообще. Связанно это с тем, что команды сами по себе были маленькие.

В целом, с самим отсутствием тестировщиков я был согласен — в этом есть смысл с точки зрения эффективного распределения ресурсов. Однако часто бывало такое, что я выкатывал прям совсем глупые баги на прод.

И каждый раз это было связанно с тем, что я поленился зайти и потыкать пару кнопок. Так как такое случалось не один раз, то я уже понимаю мой мыслительный процесс.

Обычно я все проверяю сам, пока не появляется какая-то очевидная вещь, которую кажется даже не надо тестить — там и так все просто. Особенно, если такой простой кейс сложно протестировать — нужно делать сетап в админке, получать мейлы и тд.

Часто бывает сразу пушишь коммит, проходишь ревью, выкатываешь на препрод (а иногда даже прод) и тут бац. Оказалось там не правильно написан if. Либо же опечатка в типизации, что следовательно ведет за собой опечатки в коде и тд.

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

Как вы сами понимаете, мое понимание может сильно отличаться от реальности.

На самом деле я встречал коллег, у которых вообще нету такой проблемы. Даже я бы сказал обратное — слишком датошно смотрят каждую деталь.

Однако для себя я понял решение. Если я чувствую, что я не достаточно хорошо все проверил, либо же там реально значимые изменения — я попрошу протестить еще раз кого-нибудь из разработчиков либо продуктов. Обычно никто не отказывает.

Соотвественно другим я тоже помогаю в тестировании. И причем я заметил, когда тестируешь чужой код — таких проблем нет. Всегда все нормально проверяешь.

Как-то так! А есть ли у вас проблемы с тестированием своих задач?

#devtips #testing