Comments 7
В итоге, хороший код — тот, который весь покрыт unit-тестами.
Сильное заявление. Проверять я его, конечно, не буду
Это же почти дословная цитата, цитаты из вступления к книге "Чистый код", Мартина. Удивительно, что тимлид не успел проверить это весьма обыденное заявление.
Я проверял это на себе.
В итоге код тестов заметно превышает объем основного кода. В приложении тесты чаще падали не потому, что в логике ошибку я допустил. А потому что сами тесты переставали соответствовать новой логике.
Новый параметр на входе функции увеличивает количество тестов в два раза или больше. Зависит от вариаций, которые могут поступить на вход. Если параметр передается дальше в другой компонент, то и там тесты надо усложнять.
Со стороны отдельно метода кажется, что вариаций может быть много, и все надо протестировать. Но если посмотреть со стороны интерфейса пользователя, то набор входных данных может быть ограничен факторами, о которых бекенд разработчик не знает. То есть он будет писать лишние тесты.
При рефакторинге я удалил все юнит-тесты и переключился на интеграционные. Теперь все приложение можно рефакторить сколько угодно. И стек интеграционных тестов и самого приложения можно менять независимо. Лишь бы основной интерфейс оставался рабочим.
Если на проекте нет хорошего ТЗ, и работаете по аджайлу, то заниматься юнит-тестами дорого. Уже после первого тестирования нового функционала, могут решить все переделывать. Каждый спринт будете все тесты переписывать.
В таком случае тесты лучше добавлять на устоявшийся функционал, когда думаете, что кто-то может его легко поломать. Так как все нюансы не всегда очевидны.
Вы сейчас описали признак проблем в архитектуре приложения.
Мы работаем по аджайлу и у нас легко и быстро покрывается код unit тестами. Весь код делится на отдельные модули по SOLID и DDD.
А потому что сами тесты переставали соответствовать новой логике.
Тесты тоже нужно сопровождать и именно из-за этого они должны быть максимально простыми.
В смысле? Вы рефакторите, и не тестируете после этого? Честно говоря, то, что вы описали - это мотив руководства СИЛОЙ внедрить юнит-тестирование и контролировать покрытие кода.
Unit-тестирование — мастхэв?