Тесты вредны для разработчиков

Технические менеджеры удивляются — почему разработчики не пишут тесты. Тесты полезны! Почему они их не пишут? Обычный ответ: они не хотят писать тесты, или на них слишком сильно давит бизнес. Это правильно, но недостаточно глубоко.

Будучи разработчиком уже более 40 лет, я не могу жить без тестов. Я считаю, что модульные тесты — одно из величайших изобретений нашей профессии. Для меня они являются частью ответственности разработчика. Тесты дают мне уверенность, они говорят мне, что все правильно. Все проходящие тесты, горящие «зеленым» цветом, вызывают у меня теплое чувство гордости. Всякий раз, когда я пишу больше тестов для существующего кода, я нахожу ошибки. Я не следую TDD, а пишу тесты, как только понимаю, как может выглядеть конечный код. Постоянное переписывание всех тестов многих разработчиков раздражает. Но писать тесты после того, как вы закончили программирование, уже слишком поздно, они не помогут вам в рефакторинге. Очень важно найти правильный момент для написания тестов для нового кода.

Тесты дают моему коду ориентиры. Когда я начинаю работать, я запускаю все тесты и знаю, что у меня есть рабочее состояние для начала. Когда я заканчиваю работу, я выполняю все тесты и знаю, что могу остановиться.

Но вернемся к теме.

Каждый технический директор, с которым я общаюсь, считает, что у него недостаточно хорошее тестовое покрытие, что у него недостаточно тестов. Так если тесты настолько хороши, как я их описал, то почему их слишком мало? Почему возникает такая ситуация?

Тесты вредны для разработчиков. Вот почему.

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

Если ошибка обнаружена в процессе разработки, разработчикам необходимо написать исправление, и это время засчитывается как «время разработки». Их обвиняют в срыве сроков. Их спрашивают, почему все так долго делается. Как ни странно, их обвиняют в том, что они создают качественный код. Грустно, я знаю.

Когда в проде обнаруживается ошибка, если только их не слишком много, то в этом часто обвиняют QA (позвольте мне сказать, что QA не отвечает за качество, разработчики должны владеть своим материалом — не позволяйте QA писать тесты!) Когда ошибка обнаружена в проде, ее исправление попадает в спринт вместе с историей. При обнаружении ошибок в готовом приложении могут быть добавлены специальные спринты для их исправления. Все это запланированное время. Но если ошибка обнаружена в тесте во время разработки, то она противоречит обязательствам спринта. Может потребоваться обсуждение с руководством продукта. Если ошибка обнаружена в проде, то это происходит в будущем, когда времена могут быть более счастливыми, а не сейчас, когда на нас оказывается такое большое давление. Иллюзия, я знаю.

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

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

Как выйти из этого положения? Тесты не должны подлежать обсуждению. Тесты — это часть профессиональной деятельности инженера. Меньше времени, больше давления, можно ли сократить тесты? Нет! «Кодовая обезьяна думает, может, менеджер хочет сам написать эту чертову страницу входа в систему», отвлекусь я.

Никаких коротких путей. Если у вас есть QA-инженеры, то вместо тестирования они должны просматривать тесты, написанные разработчиками. Они могут убедиться, что тесты проверяют правильные вещи. Они могут помочь разработчикам написать более качественные тесты. Они могут помочь разработчикам написать тесты таким образом, чтобы их можно было легко изменить в соответствии с меняющимися требованиями (подсказка: если у вас нет кастомной доменной библиотеки для вашего сайта/приложения, на основе которой можно писать тесты, вроде user := LoginPage().Fill(email).Login(); assert(user.LoggedIn == true), то вы делаете это неправильно).

Таким образом, если тесты вредны для разработчиков, то они не будут писать тесты. Парадокс решен. Чтобы получить преимущества и сделать тесты хорошими для разработчиков, необходимо писать тесты, без исключений, в течение некоторого времени. Заставьте тесты работать на разработчиков, и они будут писать их больше.

Источник