Самый ценный совет, который я получил в начале карьеры программиста: пишите юнит-тесты.
У многих неопытных разработчиков требование написать их вызывает прокрастинацию или скуку.
Я до сих пор иногда ленюсь, но все равно делаю это. И тут речь не про то, что в Авито для бэкенд-разработчика написание юнитов на свою логику считается в большинстве случаев необходимым требованием, чтобы тебе одобрили пул-реквест, но больше про то, что я реально понимаю ценность этого.
✍️ Почему важно писать юнит-тесты:
Фактически это гарант того, что основные кейсы, на которые вы написали юниты, работают, и ваш QA, опираясь на них, сможет сузить скоуп тестирования и больше уделить внимания сложным краевым случаям.
С вероятностью 90% после написания тестов вы так или иначе сделаете фикс в свою бизнес-логику: где-то пропустили проверку на нулевой указатель, где-то забыли обработать ошибку, где-то вышли за предел массива при случайном наборе данных, а может элементарно вы что-то не учли или после тестов поняли, что лучше будет добавить еще один слой абстракции.
Это сильно поможет в поддержке большой кодовой базы. Например, когда над проектом работает множество команд, то нет ничего проще, чем случайно задеть чье-то незадокументированное поведение. Если будут написаны юнит-тесты, то вы это сразу заметите при очередном прогоне линтера (он должен быть настроен и каждый раз прогоняться на CI/CD).
Еще это помогает рефакторить. Мне, например, очень сложно будет решиться сесть за рефакторинг какой-либо логики, если не будет юнитов (отталкиваемся от того, что тесты качественно написаны).
На код-ревью я всегда обращаю внимание на наличие юнит-тестов. Если их нет, то я не понимаю протестировал ли автор свой код.
Просите покрывать новую логику тестами или обсудите почему это нельзя сделать в моменте, обращая внимание на общую сложность тестирования функций (возможно проблема в коде, что его невозможно легко протестировать, что уже говорит о его запахе).
Пункт #2 у меня появился неспроста - это фактически отражение моей практики.
История из опыта
Буквально на прошлой задаче, когда у меня был готов ПР и одобрен оунером сервиса, я заметил, что не написал юнит-тесты на определенную часть логики предназначенной для одной платформы.
В итоге я потратил дополнительный час на тесты, в ходе которого заметил баг, влияющий на функционал при определенных условиях на десктопе. Это был корнер кейс, который было бы невероятно сложно отловить в ходе ручного тестирования (QA был явно доволен).
Вот так простая привычка писать тесты и беспокойство по их отсутствию помогли нашей команде избежать неприятного бага в будущем, на траблшутинг которого потребовалось бы явно больше времени, чем час затраченный на тесты + финальные правки.
Я не просто называю это привычкой, так как навык по написанию тестов на свой код должен стать именно ей. Со временем это будет частью вашей культуры, которую вы начнете транслировать более молодым инженерам и не заметите, как ваша кодовая база значительно прибавила в качестве.
💪 Как можно выработать эту привычку?
В IDE можно настроить code coverage. Но он может раздражать.
У меня нередко были ситуации, когда я не мог пройти линтер в сервисе, получая предостережение: Low code coverage: 90.0 < 90.0
Возможно, порог в 90% покрытия тестами избыточен, но 70% - это адекватный минимум, который должен быть.
По существу здесь работают все те же правила, что и с другими полезными привычками. Конкретно я как-то специально ее не прививал и не вел трекер с 21 днем… я просто себя заставлял это делать регулярно, начиная с первых дней в профессии.
Поверьте, когда вы в ходе написания юнит-тестов пару раз найдете несколько стыдных ошибок, то будете настолько счастливы, что они не попали в прод или даже не ревью, что это автоматически превратится в привычку.
Читайте оригинальный пост и присоединяйтесь к обсуждению в Телеграм: @time2code