Mně to taky nedá se nepřidat ;-) Je potřeba rozdělit projekty na dva druhy: -zákaznický soft -krabicový soft
Zákaznický soft je do velké míry zákazník-driven, takže bez dokonalé cyklické analýzy a prototypování jste s XP víte kde :-). Tady je přímo nutností napsat testy na úrovni externí komunikace (pakliže to jde) a na úrovni integrity dat. Nejdřív jimi musí projít prototyp a pokud jimi projde, máte vyhráno. U krabicového softu je to malinko o něčem jiném, Důvod je v tom, že invence kodéra má mnohem větší význam. Ale je potřeba si uvědomit, že ve velkých firmách to není kodér, kdo definuje funkcionalitu a tedy kdo vlastně zastupuje onu roli druhé strany barikády. Zase zde musí být jasné zadání. Pokud je ve formě Hele, udělej skladové hospodářství pro malé a střední firmy, je to na kodérovi. Pokud je ale specifikace mnohem přesnější, na Vás je, abyste analýzou dokázali, jak ony požadavky splnit. A ideálně doplnit testy na ony požadavky. Přesto jsou interní JUnitové testy jednou z velmi důležitých bodů a doporučuji, aby v rámci týmů byla vždy stanovena požadovaná CodeCoverage JUnit testů. Pokud je menší než 20%, vůbec bych se o nich jako o funkčních testech nebavil :-) Z tohoto tedy jasně vyplývá, že z mé zkušenosti jediný opravdu schůdný a udržitelný způsob vývoje je: 1) Podepsaná analýza definující požadavky a způsob jejich řešení. Jakákoli změna z té druhé strany znamená změnu v ceně, datumech a zase musí být podepsaná. Kryjete si tím záda. Ale papírově to být nemusí. E-mail je dostačující. Ušetříte si noční můry v podobě probdělých nocí těsně před releasem, kdy se v den code-freezu zjistí, že něco funguje jinak než bylo požadováno :-) 2) Automatické Testy (JUnit,...) na požadovanou funkčnost. Co nejde zautomatizovat, mělo by být popsáno formou krok-za-krokózní docky popisující vstupy a výstupy. Čím dřív se napíšou, tím lépe. Ušetříte spoustu času při předávání při vysvětlování, zda něco funguje či nefunguje, při testech celé aplikace před předáním a odhalením závažných chyb během vývoje - nemusíte čekat na testery. 3) Komponentovost. Je potřeba při psaní analýzy uvažovat, jak co nejvíce izolovat funkcionalitu pro potřeby znovupoužitelnosti kódu. Ušetříte spoustu času tím, že převezmete svůj starý nebo cizí kód. 4) Dělejte design komponent! Ušetříte spoustu času tím, že budete minimalizovat přepisy. Ideálně by součástí designu měly být testy komponenty z bodu 2). Po takovém designu máte vyhráno. Většinou mi stačí napsat dva tři odstavce dokumentace, namalovat klidně rukou seqenčák a napsat testy. Takže: a) Dokumentujte! Ušetříte spoustu času svým kolegům při čtení vašeho kódu. Rozumné pojmenování beru jako samozřejmost. b) Pište testy! Každá vrstva, každá jednotka musí mít své testy. Ušetříte spoustu času při ladění. Dobře napsaný test je výhra. Navíc se velice rychle odhalí změna funkcionality při mezitýmové spolupráci. Doporučuji dokumentovat historii testů - o změně testů by měl být informován člověk, který je závislý na testovaném kódu. Velmi se osvědčilo spojení Bugzilly a CVSka (klasické cvs commit -m "test changes during fixing bug #123456789 - ............") 5) Hlavní je funkcionalita a termíny a funkčnost. V tomto pořadí. S tím prostě nic nenaděláme, ať chceme nebo ne. Heslo každého produktového managera je Known Issues to spraví ;-) Ale já nevím jak vy, ale raději dodávám kód BEZ known issues a když už nějaké jsou, tak musí mít své testy, protože jinak jsou to UNknown issues. -- Oto 'tapik' Buchta, [EMAIL PROTECTED] http://www.buchtovi.cz ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
