TDD и приятели - част 2

И все пак, мениджмънтът е наредил да се пишат тестове, да се работи по TDD - "трябва" да го правим - да пишем unit тестове.

Прескачайки тривиалните случай стигаме до момент когато или нямаме код срещу който да тестваме, или сценарият е прекалено сложен. Опираме до "mockups". Повтаряме работа, макар и не изцяло - все пак този мок-ъпите трябва да правят нещо.

Използвайки така направените фашливи обекти - доволни и щастливи правим нашият тест и минаваме към следващата задача. Без да сме свършили нищо.

* Ако нямаме код срещу който да тестваме - виж предния пост.
* Ако имаме: и е прекалено сложен, за да направите тест кейс - или не сте за тази длъжност, или кодът не е за това място, а за /dev/null (евентуално и двете)

Твърдението, че с мокъпс е 1/1 като с реални обекти е същото, като онзи лаф за жирафите и чукчите. "Лос нали си виждал? Е нема нищо общо!

Нека да разгледаме малко по-дълбоко защо се получава така. Когато си представим даден софтуер - повечето хора си представят какво прави, как изглежда. И едва след това започват да мислят как да го направят. Или така нареченият Top-down design. И когато тестовете трябва да вървят преди или паралелно на top-down разработката, то опираме до мокъп обекти и нечий съкровени мечти.

Нека видим как седи положението при bottom-up design и разработка. С или без тестове, имаме детайлна имплементация на ниско ниво. Тестовете могат да бъдат фокусирани в/у нея, да я обхванат в много по-голяма степен. Също така, веднъж тествана можем да разчитаме на нея по-нагоре в процеса на работа. Бройката на тестовете не се умножава за всеки нов случай като при top-down, а намалява спрямо кода от високо ниво и употребата на абстракции. (ако пишете bottom-up, и нещата не стават по-лесни и по-прости - you're doing it wrong) Не се налага употребата на mockup зомбита.

Изводите за мястото и посоката на unit тестовете остават за вас :)