TDD и приятели

Без значение дали обичате или ненавиждате пратиката "TDD", дали я смятате за нещо добро, или за карго-култ, факт е, че голяма част от компаниите в последно време експериментират с него.

В тестването няма нищо лошо. Даже напротив, прекрасно е да имаш тестове, особено regression такива. Необходимо е да имаш тестове, когато пишеш safety-critical приложения.

Test Driven Development практиката твърди, че тестовете трябва да се пишат преди самото приложение. Тъй като не всеки има кристална топка или може да гледа на боб или на кафе, нека приемем, че се налага тестовете да бъдат изготвени от дадена спецификация.

Спецификацията определя дали искаме круша или ябълка. Без нея, бихме могли да направим и диня, и няма да сме отговорни :) (упражнение за HR/Management - нека всеки участник във вашия екип нарисува една ябълка. След това една круша. Сравнете резултатите) Казано иначе, ако една спецификация е пълна на 100%, то това е еквивалетно да написването на приложението. (Някой да обича да върши една и съща работа много пъти ?) Ако една спецификация обаче не е пълна, то неуточнената част от нея е оставена в ръцете на имплементиращите я.

Да се върнем на тестовете. Как може да напишете тест, за нещо, за което нямате спецификация, и не знаете какво ще бъде ? :) (време за размисъл)

В още по-лошият случай, когато се опитате да извършите неопределено действие от такъв характер ангажирате или себе си, или екипът от другата страна на повторна работа. (Ако уцелите, бягайте към тотализатора!) Или вие ще трябва да преправяте не-актуалните тестове поради непълната спецификация, или друг ще трябва да преправя не-актуалната имплементация поради непълната спецификация.

Но нека се ограничим в *разумния* случай, когато имамте тестове само и изцяло по спецификацията. В резултат - имаме не-тестван код, с евентуални грешки и дефекти. По едно случайно съвпадение, най-често недефинираната част от една спецификация са детайлите по имплементацията, а там най-често са най-проблемните за диагностика и отстраняване бъгове.

Още повече, много често писането на тестове е работа тип set & forget. Веднъж написани, рядко се екстендват или променят. Така неволно превръщаме юзърите ни в quality assurance, и чакаме те да докладват скритите проблеми.