Разработчик Майкл Нуньес в своей статье рассмотрел ситуации, когда вы должны ввести или увеличить тестовое покрытие, и рассказал о том, как это выгодно для вас и вашей команды.
Наличие в продакшене кода с хорошим тестовым покрытием очень полезно для команды разработчиков. Широкое покрытие может улавливать баги и непреднамеренное поведение, и каждый из нас может спать спокойнее, но когда база кода не имеет большого тестового охвата (или вообще никакого), его может быть очень сложно внедрить.
Будучи огромным сторонником тестов, я прилагаю усилия, чтобы добавить тесты в каждый проект, над которым работаю. Однако бывают случаи, когда тесты просто не выгодны. Например, при работе с устаревшей кодовой базой (внутренним API, который редко обновляется) добавление тестового покрытия не так выгодно.
Если ваша устаревшая кодовая база работает как нужно, проведение тестов задним числом может просто подтвердить то, что вы и так уже знаете и что уже проверено на производстве. Часто устаревшие части приложения выступают в менее важной роли, поэтому я предлагаю сосредоточить свои усилия на тестировании нового API, использующего старый код.
Все еще не уверены в преимуществах покрытия?
Вот некоторые преимущества для увеличения тестового покрытия:
- Уверенность в том, что ваш код работает должным образом.
- Развертывание кода с большей уверенностью.
- Уменьшение вероятности ночных телефонных звонков.
Уверенность в коде
Добавление тестов побуждает вас представлять в голове, как ваша программа могла бы себя вести и учитывать крайние случаи.
Развертывание кода
Чем больше ваше покрытие, тем увереннее вы можете быть в том, что новые функции не приведут к регрессионным ошибкам. В случае, если при развертывании кода случается ошибка, тесты могут служить в качестве документации для отслеживания ошибок.
Ночные телефонные звонки
Справляться с чрезвычайными ситуациями невесело. Невесело и человеку, который вам звонит. Увеличенное тестовое покрытие поможет предотвратить баги, из-за которых вы просыпаетесь по ночам.
В будущем вы оцените это.
Хорошо, как я могу начать добавлять тестовое покрытие?
Я предлагаю сначала написать тест для новых функций. Таким образом, покрываются новые изменения в базе кода, а среди членов команды и новых сотрудников начнут формироваться хорошие привычки.
Следующим приоритетом должно быть добавление покрытия для существующего кода, но это нужно делать гораздо более тщательно.
Как правило, есть два способа:
- Отмените существующую реализацию, по одному модулю за раз, и протестируйте код.
- Добавьте тесты для оценки существующего кода.
Первый способ
За:
- Это, скорее всего, приведет к улучшению дизайна и четкости кода.
- Тесты будут служить формой документации для ваших товарищей по команде и для вас в будущем.
Против:
- Отказ от существующего кода может привести к тому, что вы упустите конкретный бизнес-кейс, который не был отображен в реализации.
Второй способ
За:
- Как правило, это более быстрый процесс.
- Наличие тестового покрытия существующего API может упростить улучшение.
Против:
- Может работать, чтобы просто проверить плохой дизайн.
Побочные эффекты
Тестирование, безусловно, имеет кривую обучения, поэтому ваша команда может потратить время, чтобы выяснить, как лучше всего тестировать новый и старый код. Это может привести к снижению скорости спринта и может потребовать более сложной оценки пользовательской истории.
Тем не менее, добавление тестов к новым функциям уменьшит количество багов, а добавление покрытия к существующему коду будет компенсировать технический долг, который может оказаться разрушительным, если он останется нетронутым.
Итог: увеличение тестового покрытия улучшит дизайн, повысит доверие и сплоченность команды и уменьшит стресс, связанный с регрессионными ошибками.
