Има една история (от tdd), че дебъгването Is Evil. Дебъгването като процес на фиксване на бъгове трябва да бъде подменено с писане на тестове, които „доказват“ бъга, и според които го фиксваш.
– Из българският пощенски списък за Ruby on Rails
Искам да добавя нещо, макар да съм сигурен, че автора на горното е наясно. Целта на дебъгването е да разбереш как точно работи приложението ти, а не да ти идентифицира бъговете (съответно името му може би е малко грешно). Това за което протестира една част от програмистското население: тъпо e да ползваш дебъгване вместо unit тестове. Например да изпълниш кода в дебъгера след като го напишеш за да се увериш, че работи. Да го зачеркваш дебъгването от картинката по тези причини е като да забраняваш предефинирането на оператори – премахваш един много полезен инструмент, за да “предпазваш от грешки” хората, на които не им се мисли много.
Но обратното също е доста лоша идея – да използваш тестването вместо дебъгване. Последното ти дава подробна информация как работи отделен пасаж от кода, докато тестовете служат да правят системата по-устойчива на промени. Теста ти помага да откриеш че има проблем, докато дебъгването – да намериш някакво решение. Съответно, колкото и подробни и задълбочени тестове да правите, те няма да ви помогнат да намерите off-by-one грешката или мястото, където предавате една променлива вместо друга.
Съответно цитираното ми звучи като стандартния резултат от игра на развален телефон в ИТ бранша. Някой казал „„Това че пускате кода в дебъгера не е достатъчно добър гарант“
“, друг добавил „„Да, по-добре пишете тестове, вместо да ползвате дебъгера за това“
“ и преди човек да се осъзнае, вече е широко разпространено мнение в мрежата, че TDD зеалотите отричат дебъгера и съответно или са нещастници и съоветно цялата им философия е тъпа или трябва и ти да почнеш да „отричаш дебъгера“, ако искаш да си част от готината им групичка. Както да го погледнеш, не е на добре.