Reproduce first debugging (отладка через повторение)

В TDD (Test driven development) есть простое правило — test-first. То есть, сначала напиши тест, а потом уже код. По сути это нужно для постоянного автоматического контроля того, что ты всё делаешь правильно. Сначала пишешь тест, он фейлится, ты исправляешь код, тест начинает срабатывать — цикл закончен.

А можно ли этот же подход перенести на другие области разработки? Например на отладку?

Reproduce first debuggingКонечно можно. Представляю вам мою адаптацию концепции TDD для отладки — Reproduce first debugging (отладка через повторение).

Итак, начнем издалека.

Можно утверждать, что все программисты скажут, что правильный баг — это тот баг, который легко повторить. Раз его можно повторить, то его можно и исправить. Но значит ли это, что все они сначала повторяют баг, а потом его исправляют? Не совсем.

Многие баги кажутся достаточно простыми и их исправляют сразу без всяких проверок и повторений. И это кажется правильным, т.к. тратить часы на создание теста или установку энвайромента, если очевидно, что надо только в одном месте одну переменную увеличить на 1 — это перебор.

Но на самом деле тут всё также, как и с юнит-тестами. С одной стороны, хорошее покрытие юнит тестами уберегает от ошибок в будущем, а с другой — занимает больше времени в настоящем.

Также и с отладкой — повторить баг бывает в десятки раз сложнее и дольше, чем исправить его. Но зато исправление будет точным и правильным. А можно просто исправить что-то, что программист посчитал возможной причиной бага. Но можно ли быть уверенным в правильности этого исправления, если баг не можешь повторить и исправление не можешь проверить? Риторический вопрос.

Итак, никто наверное не будет спорить, что повторять ошибки перед исправлением — это хорошо. Чтобы это не было слишком дорого, часто эту работу кладут на плечи тестировщиков. Программист просит их повторить баг, а сам приходит уже только после повторения. Также и с энвайроментом — можно кого-то попросить его настроить.

Но вот баг найден, энвайромент настроен, баг повторяется и очевидно, как его исправить — что делать дальше?

Представим, что вы просто исправили баг, закомитили, сделали новый билд и закрыли баг в багтрекере. Опять же, потратилось немало времени на репродуцирование бага, зато исправлен он был быстро и, можно быть уверенным, качественно.

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

Но есть другой путь.

Можно потратить еще немного времени на этапе исправления бага и создать тест (system test, unit test, regression test — что угодно, что поможет поймать этот конкретный баг), который будет проверять наличие этого бага без сложной настройки энвайромента.

Это может быть простой exe файл, скрипт на любом скриптовом языке, даже просто bat файл — что угодно, если вы можете запустить это и увидеть, есть ли баг или нет. Создать такой тест зачастую бывает непросто и надо признать — вообще-то это может занять даже еще больше времени, чем настройка энвайромента и ручное повторение бага.

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

И, самое главное, вы можете встроить этот тест в свою систему автоматического тестирования, которая у вас, конечно же, есть. А если её и нет, то вы можете написать простой bat файл, который просто будет все эти тесты по очереди запускать. Даже такой bat файл даст вам +10 к уверенности в качестве продукта.

И опять же, получится всё, как в случае с юнит-тестами — со временем у вас накопится куча таких системных тестов, проверяющих баги, и вы сможете гораздо увереннее изменять свой продукт.

Чем больше таких тестов — тем больше уверенность, что вы ничего не сломали. Вопрос только в одном — готовы ли вы сейчас потратить больше времени на разработку, чтобы в будущем тратить меньше времени и иметь более качественный продукт?

Оставить комментарий