Тестовое сокращение технического долга
Технический долг принимает множество форм, не обнаруживаемых модульными тестами
Например:
- Имена функций API написаны на суахили. Команда говорит только на эсперанто.
- В кодовой базе используется KORBA. Никто не поддерживает KORBA.
- API сериализатора, предоставленный подрядчиком, работает безупречно, но не соответствует руководству по стилю.
Вы можете подумать: о, подождите, руководство по стилю! Мы можем проверить его на соответствие с помощью инструмента статического анализа. Но нет. Потому что любое приличное руководство по стилю требует большего, чем просто зеленый свет от подключаемого модуля. Устранение технического долга - это забота о том, чтобы люди были счастливы. А не процессор.
Вы можете найти несколько способов автоматизации тестов для устранения технического долга. Но вы в значительной степени упускаете суть. Лучший инструмент для борьбы с техническим долгом - это обзор кода. Если кто-то проходит лишнюю милю, исправляя свой тикет, и случайно меняет названия некоторых функций на понятные вам, скажите ему спасибо.
Если вам удастся создать набор автоматизированных тестов на технический долг, пожалуйста, поймите, что то, что вы создали, также является кодом. Код, который будет иметь свой собственный технический долг. Поэтому будьте осторожны, как глубоко вы спуститесь в эту кроличью нору.
Технический долг всегда должен рассматриваться как оценочное суждение. Не существует идеальной оценки. Есть достаточно хорошо, а есть "вы еще не закончили?".
Если подумать, существует автоматизированный тест на технический долг, который предоставляет очень полезную метрику, не создавая большого собственного долга. Я использовал его в течение многих лет. Работает он следующим образом:
grep -r "//TODO" . | wc -l
Рекомендую посмотреть эти видео для лучшего погружения в вопрос: