И все пак, мениджмънтът е наредил да се пишат тестове, да се работи по 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, и чакаме те да докладват скритите проблеми.
Вторник, Април 19, 2011
Колелото, глината и гърнето в IT
Всички знаем, че можем да постигнем желан резултат в дадени граници по много различни начини. Но за разлика от древните занаятчии, които след като са оформяли желаният съд са го изпичали, то на нашите съдове им се налага да бъдат flexible, adaptable, malleable, configurable, extendable, scaleable, enterprise-able и т.н. и т.н.
Грънчарите работейки обаче само със съставките на крайния си продукт не са имали необходимостта от нови и различни по вид колела. Поправяли са свойте и пак са продължавали с изпипаните си техники.
Непрекъснато променящите се изисквания на клиентите на IT индустрията от своя страна налагат нуждата от вече съществуващи инструменти които могат да бъдат пригодени към задачите или изцяло нови такива. Или иначе казано, когато имаш тесла и голям брой пирони - или ще се роди нещо което да ги забива само, или нова тесла с повече от 1 глави :)
Заменили сме занаятчийските степени с университетски дипломи и сертификати от курсове. И въпреки всичко, когато опре до работа, честа практика е на senior служител да бъдат прикачани junior такива за обучение :)
Прегърнали сме отвореният пазар. За никого не е пречка да стане програмист - стига да желание. Няма книжки, няма изпити, няма 7 години чиракуване. Заменили сме ги с опит и репутация. И също както старите занаятчии са показвали свойте изработки показваме и се годеем с нашите.
Загубили сме гилдиите, но не и обединените усилия - софтуерът с отворен код и общността от потребители и разработчици около него са тук, и по всичко личи, че ще останат и за напред.
Запазили сме know-how школите. Начинът на работа, декорациите, щипка артистичност и хитрините.
LT;DR / Накратко - ние сме занаятчиите в IT индустрията.
Грънчарите работейки обаче само със съставките на крайния си продукт не са имали необходимостта от нови и различни по вид колела. Поправяли са свойте и пак са продължавали с изпипаните си техники.
Непрекъснато променящите се изисквания на клиентите на IT индустрията от своя страна налагат нуждата от вече съществуващи инструменти които могат да бъдат пригодени към задачите или изцяло нови такива. Или иначе казано, когато имаш тесла и голям брой пирони - или ще се роди нещо което да ги забива само, или нова тесла с повече от 1 глави :)
Заменили сме занаятчийските степени с университетски дипломи и сертификати от курсове. И въпреки всичко, когато опре до работа, честа практика е на senior служител да бъдат прикачани junior такива за обучение :)
Прегърнали сме отвореният пазар. За никого не е пречка да стане програмист - стига да желание. Няма книжки, няма изпити, няма 7 години чиракуване. Заменили сме ги с опит и репутация. И също както старите занаятчии са показвали свойте изработки показваме и се годеем с нашите.
Загубили сме гилдиите, но не и обединените усилия - софтуерът с отворен код и общността от потребители и разработчици около него са тук, и по всичко личи, че ще останат и за напред.
Запазили сме know-how школите. Начинът на работа, декорациите, щипка артистичност и хитрините.
LT;DR / Накратко - ние сме занаятчиите в IT индустрията.
Сряда, Март 30, 2011
Понеделник, Март 28, 2011
Слонски работи :D
Man goes to the doctor after being raped by an elephant. The Dr says:
- Funny, your ass is 10 inches wide but an elephants co-ck is only 3 inches wide!
To which the man replies:
- Well, the bastard, fingered me first.
- Funny, your ass is 10 inches wide but an elephants co-ck is only 3 inches wide!
To which the man replies:
- Well, the bastard, fingered me first.
Четвъртък, Декември 23, 2010
Понеделник, Ноември 08, 2010
Stay a while and listen (p2)
-
Pretty flowersand muddy roots beneath
A façade to behold
-
Thousand thoughts
Like cherry blossoms
Write documentation
-
Moribana or seika
The code does not care
Lint is it's Tao
-
Абонамент за:
Публикации (Atom)
