Как инициировать модульное тестирование, когда вы хрюкаете?

Вы работаете над проектом S, которому не хватает ни CI/CD, ни даже возможности увидеть зеленую полосу NUnit. Предположительно, он экспортирует как минимум одну общедоступную функцию, которую вы можете вызвать. Создайте проект T, который вызывает одну или несколько функций S. Позже вы можете решить, рассказывать ли кому-нибудь о Т. Включите любые внешние зависимости, которые вам нравятся, проверьте некоторые тривиальные свойства, и полюбоваться зеленой полосой. Дождитесь следующего сеанса планирования спринта.

Вам назначен новый элемент, функция или исправление, поэтому вы добавите в S как минимум одну новую публичную функцию. Вам придется запускать этот код более одного раза и оценивать его результаты. Избегайте printf отладки или просмотра графического интерфейса или какой бы подход обычно не использовался с S. Напишите красный (неудачный) тест в T, затем повторите, пока он не станет зеленым. На данный момент у S есть хороший код, предназначенный для успешного завершения спринта.

Когда начинается следующий спринт, вам присваивается предмет которая требует от вас взаимодействия с функцией коллеги Боба b(), но вы понятия не имеете, как это вызвать и как проверить результат. Вместо того, чтобы добавлять абзацы в некоторые файлы ReadMe, объясняющие это, просто добавьте автоматический тест, который охватывает b(). Теперь, когда вы вносите изменения, вы можете сказать, сломали ли вы что-то или, во всяком случае, сломали ли вы скрытое поведение, представляющее интерес. Добавьте свою новую функцию f(), которая вызывает b(), и напишите для него тест. Закрыть спринт и S, и T находятся в лучшей форме, чем в начале спринта. Зачем мы написали эти тесты? Чтобы повысить свою продуктивность, поэтому функция выпущена быстро и правильно.

Получите GitHub Actions или Jenkins или другой подход CI/CD для регулярного запуска тестов при отправке нового кода. По прошествии календарного времени будет развиваться история либо ложных срабатываний, либо ценных предупреждений. Решите позже, хотите ли вы рассказать кому-нибудь об этом.

Что не так с S+T? Ой, столько всего, и технического, и социального, не будем считать способы. Возможно, самым важным является то, что коммиты в обоих случаях не являются атомарными. Так что git — это не ваша машина времени. Возможно, вы сможете неуклюже синхронизировать время с помощью пары команд checkout, чтобы воспроизвести некоторую регрессию и ее исправление.

После того, как вы занимаетесь этим в течение шести месяцев, ошибка, которая настолько значительна, что для ее исправления потребуются электроинструменты, и люди будут благодарны, если им вручат хорошие инструменты. Воспользуйтесь возможностью, перетащите кучу кода в ветку "test PoC" в S, и расскажите о своем подходе. Может быть, он будет принят несколькими спринтами позже после того, как текущая чрезвычайная ситуация была отправлена ​​обычным способом, но эй, это все еще победа.

Большая часть планирования проектных инициатив направлена ​​на снижение рисков. их — систематическое изучение элементов, которые могут поставить под угрозу ключевые показатели эффективности. и выбор отказаться от предмета или принять его, возможно, с адаптациями из извлеченных уроков. Ваши инвестиции в автоматизированное тестирование служат вашей собственной производительности, и может приносить дивиденды, когда команда может ясно видеть другую набор {рисков, вознаграждений}, чем они видели в прошлом году.