И все пак, мениджмънтът е наредил да се пишат тестове, да се работи по 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 тестовете остават за вас :)
Сряда, Май 11, 2011
TDD и приятели
Без значение дали обичате или ненавиждате пратиката "TDD", дали я смятате за нещо добро, или за карго-култ, факт е, че голяма част от компаниите в последно време експериментират с него.
В тестването няма нищо лошо. Даже напротив, прекрасно е да имаш тестове, особено regression такива. Необходимо е да имаш тестове, когато пишеш safety-critical приложения.
Test Driven Development практиката твърди, че тестовете трябва да се пишат преди самото приложение. Тъй като не всеки има кристална топка или може да гледа на боб или на кафе, нека приемем, че се налага тестовете да бъдат изготвени от дадена спецификация.
Спецификацията определя дали искаме круша или ябълка. Без нея, бихме могли да направим и диня, и няма да сме отговорни :) (упражнение за HR/Management - нека всеки участник във вашия екип нарисува една ябълка. След това една круша. Сравнете резултатите) Казано иначе, ако една спецификация е пълна на 100%, то това е еквивалетно да написването на приложението. (Някой да обича да върши една и съща работа много пъти ?) Ако една спецификация обаче не е пълна, то неуточнената част от нея е оставена в ръцете на имплементиращите я.
Да се върнем на тестовете. Как може да напишете тест, за нещо, за което нямате спецификация, и не знаете какво ще бъде ? :) (време за размисъл)
В още по-лошият случай, когато се опитате да извършите неопределено действие от такъв характер ангажирате или себе си, или екипът от другата страна на повторна работа. (Ако уцелите, бягайте към тотализатора!) Или вие ще трябва да преправяте не-актуалните тестове поради непълната спецификация, или друг ще трябва да преправя не-актуалната имплементация поради непълната спецификация.
Но нека се ограничим в *разумния* случай, когато имамте тестове само и изцяло по спецификацията. В резултат - имаме не-тестван код, с евентуални грешки и дефекти. По едно случайно съвпадение, най-често недефинираната част от една спецификация са детайлите по имплементацията, а там най-често са най-проблемните за диагностика и отстраняване бъгове.
Още повече, много често писането на тестове е работа тип set & forget. Веднъж написани, рядко се екстендват или променят. Така неволно превръщаме юзърите ни в quality assurance, и чакаме те да докладват скритите проблеми.
В тестването няма нищо лошо. Даже напротив, прекрасно е да имаш тестове, особено regression такива. Необходимо е да имаш тестове, когато пишеш safety-critical приложения.
Test Driven Development практиката твърди, че тестовете трябва да се пишат преди самото приложение. Тъй като не всеки има кристална топка или може да гледа на боб или на кафе, нека приемем, че се налага тестовете да бъдат изготвени от дадена спецификация.
Спецификацията определя дали искаме круша или ябълка. Без нея, бихме могли да направим и диня, и няма да сме отговорни :) (упражнение за HR/Management - нека всеки участник във вашия екип нарисува една ябълка. След това една круша. Сравнете резултатите) Казано иначе, ако една спецификация е пълна на 100%, то това е еквивалетно да написването на приложението. (Някой да обича да върши една и съща работа много пъти ?) Ако една спецификация обаче не е пълна, то неуточнената част от нея е оставена в ръцете на имплементиращите я.
Да се върнем на тестовете. Как може да напишете тест, за нещо, за което нямате спецификация, и не знаете какво ще бъде ? :) (време за размисъл)
В още по-лошият случай, когато се опитате да извършите неопределено действие от такъв характер ангажирате или себе си, или екипът от другата страна на повторна работа. (Ако уцелите, бягайте към тотализатора!) Или вие ще трябва да преправяте не-актуалните тестове поради непълната спецификация, или друг ще трябва да преправя не-актуалната имплементация поради непълната спецификация.
Но нека се ограничим в *разумния* случай, когато имамте тестове само и изцяло по спецификацията. В резултат - имаме не-тестван код, с евентуални грешки и дефекти. По едно случайно съвпадение, най-често недефинираната част от една спецификация са детайлите по имплементацията, а там най-често са най-проблемните за диагностика и отстраняване бъгове.
Още повече, много често писането на тестове е работа тип set & forget. Веднъж написани, рядко се екстендват или променят. Така неволно превръщаме юзърите ни в quality assurance, и чакаме те да докладват скритите проблеми.
Абонамент за:
Публикации (Atom)
