Pro většinu z nás jsou unit testy naprostou samozřejmostí a pokud budu mluvit sám za sebe, tak si to bez unit testů už nedovedu představit. Nejvíce to vidím, když opravuji starý kód, jak jsem nervózní, abych jednou úpravou neudělal další chyby.
Osobně unit testy (nebo i integrační testy, myšleno testy nad databází) píšu po napsaní produkčního kódu. Již během psaní produkčního kódu si dělám poznámky, jaké možné cestičky je potřeba ověřit a podle toho potom píši testy. Testy tedy hlavně beru jako mého pomocníka (=pomocníka programátora), abych byl schopen dodat práci co v nejlepší kvalitě a byl co nejlépe připravený na budoucí úpravy a opravy. Z pohledu samotného vývoje je asi tento pohled v pořádku, ale pokud se na proces vývoje ve firmě podívám z pohledu celé firmy, tak už tam vidím nějaké mezery.
Proces vývoje většinou začíná u konzultantů, kteří tvoří zadání, kteří definují akceptační kritéria, kteří nesou zodpovědnost za to, že zákazníkovi se dodá to, co opravdu chtěl a navíc v požadované kvalitě. Od začátku jsou tedy zřejmé požadavky, které je nutné splnit a tyto požadavky by se měly co nejvíce přenést do samotného vývoje. Je tedy žádoucí, aby programátoři se během vývoje a testování zaměřili právě na tyto důležité požadavky. Často programátor testuje věci dle svého uvážení, kde on sám vidí možné slabiny, ale to je často v rozporu s tím, co musí testovat konzultant/tester.
Právě při těchto úvahách jsem hledal možné řešení, jak co nejvíce propojit obě části vývoje, jak najít společnou řeč. Nejblíže mojí představě je Acceptance test driven development a konkrétně projekt Thucydides, který celému přístupu dává jasné obrysy.
Advanced practices of test-driven development can lead to Acceptance Test-driven development (ATDD) where the criteria specified by the customer are automated into acceptance tests, which then drive the traditional unit test-driven development (UTDD) process. This process ensures the customer has an automated mechanism to decide whether the software meets their requirements. With ATDD, the development team now has a specific target to satisfy, the acceptance tests, which keeps them continuously focused on what the customer really wants from that user story.Místo vysvětlování ATDD a Thucydides se doporučuji podívat na prezentaci pod článkem, kde je vše pěkně ukázané. Pro další informace pak ještě doporučuji článek z JavaWorldu - Acceptance test driven development for web applications.
Ještě bych zmínil knihovnu jBehave, která je představitelem přístupu zvaném Behaviour-Driven Development (BDD), který je velice podobný ATDD.
Rádi bychom šli v celém návrhu ještě dále a využili JIRU jako nástroj pro psaní a evidenci kritérií resp. stories. JIRA je pro většinu týmu centrálním bodem, kde se evidují požadavky na vývoj a je to i nástroj, který umí používat konzultanti. Tak proč neupravit JIRU i pro zadávání akceptačních kritérií v určitém formátu, ze kterých by se následně generovala kostra/šablona pro psaní testů v Groovy nebo jUnit?
Nápadů a myšlenek je hodně, uvidíme v jaké podobě (a zda vůbec) se nám to podaří realizovat v praxi. Pokud máte někdo s uvedenými přístupy nějaké zkušenosti, budu rád když je uvedete v komentářích k článku.
Příspěvky
Žádné komentáře:
Okomentovat