Používáte „vývoj programu řízený testy“?

[nm]

Nedávno jsem si přečetl něco o metodice "Vývoj programu řízený testy" v knize o JAVA programování. Jedná se o metodu, při níž nejprve vytvoříte vhodné testy, kterými program testujete a teprve potom se pustíte do samotného programování. Testy pak průběžně program ladíte.

Používáte tuto metodu? Používáte jí v práci nebo i doma?

[Reklama]

[Inkvizitor]

Nepoužívám. Upřímně, přijde mi to ujeté. Samozřejmě se nedomnívám, že by někdo dělal testy na to, zda 1 + 1 == 2, jak se píše v učebnicích, ale myšlenka, že by testy měly "řídit" vývoj aplikací, podle mě poukazuje víc na deficit používaného programovacího jazyka, který nedovoluje dobře modelovat problém. Kdybych chtěl být jízlivý, přejmenoval bych TDD na MPO (metoda pokus-omyl).

[kuka]

Na neco to pouzivame, na neco ne. S deficitem jazyka to podle mne nijak nesouvisi a s metodou pokus-omyl uz vubec ne. Pokud je zamerem mit dobre pokryti testy, tak se napsat musi stejne a kdyz jsou k dispozici predem, muze to samotnemu vyvoji hodne pomoct. Protoze pokud se pisou testy dodatecne, tak se obcas nenapisou vubec a kazdiopadne vznika casovy usek, kdy testy jeste nejsou. A dobre pokryti testy je hlavne pri vyvoji ve vetsim tymu docela vyhra, potoze spolecna codebase splnuje nejake zakladni pozadavky na kvalitu (nedostane se tam kod, ktery vzdy spadne apod.) - je opravdu fatalni, kdyz deset lidi ztrati dve hodiny proto, ze nekdo "opravil" funkci ve spolecne knihovne tak, ze pro jeho potreby funguje a ostatnim zacne padat.

[Rdpanek]

TDD je celkem narocna metodika. Programtor opravdu musi vedet, co dana aplikace/jeji cast musi umet a dale musi programtor znat technologii, ci rozhranii frameworku.

Psani TDD je specifikace, jak ma program fungovat. Pri pouzivani TDD se napise malo kodu, za to kvalitniho, protoze cilem je, napsat co nejmin kodu, ktery vyhovi testu zatim co test rika, co pozdeji napsany kod ma vlastne delat.

Doporucuji TDD pouzivat

[Petr]

Tak já myslím, že TDD je například nutnost když se programuje v dynamickém jazyce - ten jazyk za programátora prostě spoustu věcí nezkontroluje a refaktoring je poměrně velké riziko - obzvlášť čím větší je tým a projekt. V tom případě pokud není program pokryt mnoha testy, je větší refaktoring šílenství.

V Javě se někde dělá, jinde ne - z mojí zkušenosti jsou úspěšné týmy i ty, které TDD dělají i ty, které TDD nedělají.

Podotýkám, že je důležité, aby testy byly opravdu jednotkové - namockovat co nejvíc použitých služeb/komponent, co to jde. Důležité je, aby test procházel i pokud ja pokažená / změněná komponenta, na které testovaný kód závisí. Jinak totiž s narůstajícím počtem testů je vůbec problém udělat úpravu kódu, aniž by člověk musel opravit stovky testů - to by totiž paradoxně s narůstajícím počtem testů vývoj zpomalovalo nebo téměř zastavilo a v té chvíli by se všichni na testy vykašlali a testy by měly nulovou vypovídací hodnotu.

[Reklama]

[Inkvizitor]

I v dynamických jazycích je možná statická analýza (my např. v Pythonu používáme Pylint); tam ta kontrola je s Javou docela srovnatelná. Úplně se na ni ovšem spolehnout nedá.

Neříkám, že jednotkové testy jsou na nic, ale obávám se, že ve větších systémech se na ně stejně nedá plně spolehnout; jsou situace, které jednotkovými testy nedají moc dobře postihnout. Čím víc se člověk snaží postihnout všechno, tím více se vývoj protahuje a pak je samozřejmě na zvážení, který náklad se ještě vyplatí.

Mimochodem, kód, který projde testy, ještě nemusí být kvalitní.

[Kit]

Mimochodem, kód, který projde testy, ještě nemusí být kvalitní.

Nekvalitní kód, který projde testy, znamená jediné: Nekvalitní testy. Nevěř testům, které projdou.

[ABC]

Z pohledu projekt manažera - teoretika bych najmul geniálního matematika, aby analyticky dokazoval správnost algoritmů. V praxi se musí řešit náklady na implementaci metodiky vývoje sw, dodací lhůty, nebo fluktuace zaměstnanců(správa know-how). Při ladění se často uvádí pravidlo 80/20, nicméně u firmy, která již disponuje řadou sw polototovarů, které se podle zadání integrují, mohou jednotkové testy urychlit dodací lhůty.

[Inkvizitor]

Jasně, testy mohou být neúplné nebo chybné, ale o to mi nešlo. Chtěl jsem říci, že jsou i jiná kritéria, např. optimalita a udržovatelnost.

Mimochodem, kód, který projde testy, ještě nemusí být kvalitní.

Nekvalitní kód, který projde testy, znamená jediné: Nekvalitní testy. Nevěř testům, které projdou.

[Kit]

Nekvalitní kód, který projde testy, znamená jediné: Nekvalitní testy. Nevěř testům, které projdou.

Jasně, testy mohou být neúplné nebo chybné, ale o to mi nešlo. Chtěl jsem říci, že jsou i jiná kritéria, např. optimalita a udržovatelnost.

Testy se dělají i kvůli těmto kritériím. Kvůli udržovatelnosti se dělá refaktoring, který se s testy dělá mnohem lépe.

Testy dělá každý. Ovšem ne každý je dělá systematicky. Když napíši sort, připravím si zkušební data a výsledek porovnám s požadavkem. Nikdo nepustí program do světa bez testu. Mezitím někdo modifikuje knihovnu nebo proběhne upgrade serveru - může se změnit prostředí. Pokud ten test mezitím nikdo nesmazal, je velmi jednoduché ho spustit znovu a ověřit si tak, že aplikace šlape stále jak má.

Testy mi také ukáží, zda mé pokusy o optimalizaci nenaruší požadavky na aplikaci. Ano, testy se dají využít jako specifikace požadavků s možností opakovaného ověřování. Když budu vývoj řídit testy, stále to ještě neznamená psaní neudržovatelného kódu.

Test považuji za další level kompilátoru či interpretru, který má za úkol odhalit logické chyby v aplikaci.

[JS]

TDD jsem nikdy nepouzival, a osobne si myslim, ze lepsi je pri programovani vyuzivat abstrakci a ruznych assertu nez testovat (protoze to jsou fakticky testy nad nekonecnou mnozinou pripadu). (A take mi prijde legracni tvrzeni nekoho tady, ze chce psat malo kodu - pokud nepisete v jazyce, ktery umi metaprogramovani, zapomente na to, ze budete psat "malo" kodu! :-))

Nicmene, ted me napada, neporusuje TDD princip "krizove validace" ve statistice? Tedy zasadu, ze pokud neco vyvijime (nejaky model reality, programy jsou specialni pripad) na nejakych datech, meli bychom ho testovat na jinych datech? Zvlaste ta predstava, ze ty testy se musi stejne napsat, tak proc to nepsat tak, aby to rovnou temi testy proslo - to je desive! Lidi, uvazujte trochu..

A jak rikam. Pokud uz povazujete za dobre mit test primo pri vyvoji, proc tam nevrazit rovnou assert, ktery je obecnejsi?

[Franta]

A jak rikam. Pokud uz povazujete za dobre mit test primo pri vyvoji, proc tam nevrazit rovnou assert, ktery je obecnejsi?

Sice nejsem nějaký skalní příznivec TDD, ale tady se musím testů zastat. Test může např. kontrolovat, že metoda vyhodí správnou výjimku, nebo že zavolá jinou metodu na nějakém jiném objektu. Nebo třeba že vrátí výsledek do určitého času. To jsou věci, které assertem nepokryješ.

A druhá věc je, že umožňují oddělit logiku aplikace od testů, takže kód není zahnojený všemožnými kontrolami (které by byly při běžném provozu stejně vypnuté a aplikovali by se jen ve fázi vývoje a testování).

[Kit]

A jak rikam. Pokud uz povazujete za dobre mit test primo pri vyvoji, proc tam nevrazit rovnou assert, ktery je obecnejsi?

Pokud někdo dává assert do aplikace, vkládá do ní testy. TDD tyto testy odděluje do samostatného kódu, který může většinu času jen nečinně ležet vedle aplikace a spouštět se jen v případě nějaké změny. Nezvětšuje tedy kód aplikace a zbytečně ji tím nezpomaluje.

[ava]

Jasne ze pouzivam, kdyz nemam po ruce nejakou *unit knihovnu a moznost testy poustet, pripadam si jak bez jedne ruky. Ted treba zrovna pisu knihovnu pro zpracovani dat nejakych mericich pristroju, kterou budou pouzivat jini, a vidim to asi nasledovne:

Stejne bych musel nejak vyzkouset, ze ta knihovna neblbne, zrejme si napsat nejaky programek ktery bude generovat/cist od uzivatele data a koukat se, jestli to dava vysledky jake ocekavam. Doufat, ze kdyz se to prelozi, tak to i spravne funguje, je furiantstvi a blbost. Proc teda rovnou nenapsat testy, ktere vygeneruji nejaka vzorova data a kouknou jestli vysledky odpovidaji ocekavani? Prace je to nakonec stejne...

Kdyz knihovnu navrhuji, snazim se o to, aby se co nejsnaze pouzivala. Kdyz si nejprve napisu testy, ktere tu knihovnu pouzivaji, dobre si uvedomim, jak verejne rozhrani navrhnout. Pak uz jen dodam implementaci knihovny :-)

Az budou chtit ostatni clenove tymu knihovnu pouzivat, musi mit nejakou dokumentaci, jak se s ni zachazi. Tests to the rescue :-) Vzdyt jsou to vlastne male priklady, jak knihovnu pouzit. Staci mi napsat nejaky textovy dokument popisujici high-level prehled knihovny a jeji rozdeleni, konkretni pouziti pak uz mohou obslehnout z testu. Navic, takovato dokumentace je vzdy up-to-date, coz se o textove da malokdy rici...

Jak rika Donald Knuth, "premature optimalization is the root of all evil", takze to pisu tak, aby to fungovalo a bylo to citelny. Az mi sef rekne "Hele funguje to dobre, ale chtelo by to 100000x zrychlit a at to zere 100000 min pameti", muzu hledat slozitejsi algoritmy a optimalizovat, a vzdy mi pak staci jen pustit testy a ujistit se ze jsem nic nerozbil.

Takze treba v tomhle pripade jasna vyhra. Jsou veci co se testuji hur (GUI, komunikace s externim prostredim, weby), ale pokud to jde, ma smysl testy psat.

[kuka]

Zvlaste ta predstava, ze ty testy se musi stejne napsat, tak proc to nepsat tak, aby to rovnou temi testy proslo - to je desive! Lidi, uvazujte trochu..
A jak rikam. Pokud uz povazujete za dobre mit test primo pri vyvoji, proc tam nevrazit rovnou assert, ktery je obecnejsi?

Asi nechapes, o jake testy se jedna. Nikdo neprogramuje tak, aby vyhovel testum, ty mu pouze pomahaji kontrolovat, ze neudelal chybu. A chyby dela kazdy. Automatizovane testy typicky kontroluji vztah vstup-vystup, pripadne aspekty chovani jako treba zavolani jine metody apod., pokud jsou definovany jako pozadavek v zadani. Ja kdyz naprogarmuju funkci, tak si ji po sobe otestuju - pokud to udelam opakovatelnym zpusobem (napr. JUnit), tak to bude moci udelat i kdokoliv dalsi, kdo tu funkci bude upravovat, a nebude ho to stat zadne usili. O to jde v automatizovanem testovani.

Kdyz vidim nektere softwarove produkty, kde se ob verzi periodicky vraceji drive opravene elementarni chyby typu "pro vice nez 8 parametru konci chybou" (u mne v tomto vedou JDBC drivery od Oracle), tak si rikam, proc nepouzivaji testy? To je presne vec, ktera se pri dobrem pokryti testy nemuze stat. Coz nesouvisi s TDD, testy nejakym zpusobem provadi kazdy, jde spis o otazku jejich efektivity.