Kent Beck's TDD screencast

[Stefan Kanev]

Прагматичните програмисти пуснаха скрийнкаст на тема ТДД скоро. Води го Кент Бек и може да го намерите тук:

http://www.pragprog.com/screencasts/v-kbtdd/test-driven-development

Горещо ви го препоръчвам. Също така, интересува ме какво научихте и какво мислите като цяло. Ето моите бележки:

• Започна с класа в същия файл като теста. Това беше интересно. Докато аз гледам да разхвърлям структурата първо и да пиша код и тест после, той го направи наобратно. Всякаш тоя стил на работа е по-подходящ в общия случай, когато нямаш ясна структура от framework-а (модели и контролери в Rails например). Ще го пробвам някой път.
• Изгради първия тест постепенно. В него ползва два метода (put и get). Започна от просто отваряне на сокет, след което постепенно добави комуникация със сървъра в теста и накрая го изнесе в отделен клас. Надграждаше в един тест, като имаше цел, към която се стремеше. В нашата фирма го правим по друг начин – опитваме се да стигнем до там с малки тестове (един за get, един за put, един за частен случай и така докато подкараме този с get и put). По нашия начин подкарването на първия смислен тест е доста по-болезнено и оставя няколко fragile test-а по пътя. Той подход също ми хареса повече.
• Написа няколко временни теста, които после изтри. Това докато имплементираше iterator. Откри, че ще му трябват два метода (reset и getNextKey), test-drive-на ги, след това имплементира итерата, след което намали видимостта им и изтри тестовете. Обикновено не трия тия тестове, което има там два неприятни ефекта – (1) с времето стават fragile и (2) налагат публични методи върху обекта. Или още по-лошо, тествам private методи.
• Добави тест за два елемента, след което изтри този за един. Това също рядко ми хрумва да го правя. Когато имам тест, който е частен случай на друг тест, обикновено се свеня да го трия, в случай че някой промени имплементацията и го превърне в частен случай. От друга страна, да мисля така не е YAGNI.
• Написа fake и след това веднага го замени с истинска имплементация. За size(). Това пък не го правя. Добавям друг тест, преди да променя fake имплементацията. Не съм сигурен дали имаше смисъл или просто искаше да покаже fake.
• Отложи разчистването до края. Бая дълго време толерираше повторението вътре в методите. В крайна сметка това беше хубаво, защото получава повече обратна връзка, но аз рядко издържам толкова дълго преди да разчистя. Това е донякъде свързано със следващата точка.
• Липсва ми refactoring support-а в Ruby. Ред от нещата сработиха добре, понеже можеше да пренареди кода доста чевръста с Eclipse. На няколко места отложи премахване на повторение, понеже беше евтино да го направи по-късно. Аз обикновено го правя по-рано, защото когато го отложа отнема повече време във vim или TextMate. Това ме навежда на мисълта, че или трябва да се науча да ползвам RubyMine стабилно, или трябва да направя нещо роботско с редактора си.
• "When you make a design decision is itself a design decision". 'nuff said. Харесвам всякакви неща, които въвеждат времевия аспект на микро ниво в писането на код :)
• Упражнение: пише някакъв код, трие го, пробва да го пише в друг ред, трие го, пробва в трети и така докато намери оптимален. За да изгради интуиция как най-добре да работи. Реминисцентно на katas и всякакви други software craftsmanship сухи упражнения. Трябва да обърна повече внимание на тая идея.

И едно за завършек:

• Не ползваше fixed-width шрифт. Просто не мога да го разбера. От друга страна, това му е стар номер и такъв е кода в Smalltalk Best Practice Patterns. Нямам си идея защо, обаче.

Вие гледали ли сте го? И ако да, какво мислите по въпроса?