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