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

[Zdeno Sekerák]

Testy maju jedno nadherne pouzitie odhaluju chyby ktore sa uz raz nasli.
Teda ked tam ma SW chybu napisem test ktory ju odhali. Pred releasom pustim testy.
Pretoze nieje nic horsieho ako ked dodate zakaznikovi SW stale s tymi istymi chybami.

[Reklama]

[JS]

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.

Test neni totez co assert. Assert testuje predpoklad, ktery ma byt splnen vzdy. Test testuje nejakou malou konecnou mnozinu pripadu (vetsinou jen jeden). Na druhou stranu, ne vse co lze proverit testem lze proverit assertem - napr. test na spravnost vysledku funkce faktorial lze tezko assertovat (aniz bychom napsali tentyz kod 2x).

Ja si myslim, ze pokud muzete zvolit mezi assertem a testem, assert je ucinnejsi. Napr. staticka typova kontrola je jedna z forem assertu. Nejucinnejsim nastrojem je ovsem vhodna volba abstrakce. Ta chybam predchazi rovnou v dusledku dekompozice problemu.

Co se tyce toho, zda se ten assert da odstranit nebo ne, zalezi na jazyku a frameworku. Uzitecne jsou oba typy assertu.

[JS]

Asi nechapes, o jake testy se jedna. Nikdo neprogramuje tak, aby vyhovel testum, ty mu pouze pomahaji kontrolovat, ze neudelal chybu.

Proti tomu nic nenamitam. Ale jak mam tedy rozumet tomu "testy se stejne musi napsat"? Pokud si nekdo mysli, ze TDD muze nahradit normalni testovani, je podle me na omylu. I ja jsem zastance toho, aby si vyvojar sve veci otestoval, ale to neznamena, ze tim lze nahradit nezavisle testy.

[kuka]

Ale jak mam tedy rozumet tomu "testy se stejne musi napsat"? Pokud si nekdo mysli, ze TDD muze nahradit normalni testovani, je podle me na omylu. I ja jsem zastance toho, aby si vyvojar sve veci otestoval, ale to neznamena, ze tim lze nahradit nezavisle testy.
[/quote]

Pokud chci mit pokryto automatizovanymi testy, musi se tyto testy napsat, to je asi jasne. TDD je metodika, ve ktere se zjednodusene receno nejprve pripravi testy a pak se  implementuje. Testy se ale klidne daji psat az dodatecne, pokud to nekomu lepe vyhovuje. O nahrade testovani jako takoveho nebylo vubec reci - cilem automatizovaneho testovani je zajistit, ze budou splneny elementarni invarianty, napriklad spravne osetrene mezni stavy apod., coz zvysuje "zakladni" kvalitu kodu a usnadnuje refaktoring a optimalizace. Testovani testery je velice drahe - zatimco cena automatickeho testu pravidla "pro prazdny vstup vraci nulu" je rekneme minuta na napsani testu, objeveni NPE na tomtez miste v ramci "nezavisleho testovani" muze stat v souctu hodiny prace nekolika lidi. To neznamena, ze prislusny scenar v uzivatelksych testech nebude, jen to zvysuje sanci, ze probehne uspesne.

[JS]

Pokud chci mit pokryto automatizovanymi testy, musi se tyto testy napsat, to je asi jasne. TDD je metodika, ve ktere se zjednodusene receno nejprve pripravi testy a pak se  implementuje.

Jadro naseho sporu je v tom, jak se TDD stavi k tomuto: http://en.wikipedia.org/wiki/Testing_hypotheses_suggested_by_the_data (Statistiku moc neznam, jen vim, ze ten problem existuje a je treba dat si na nej bacha.) Tedy, jinak receno, jsou ty testy dostupne neomezene behem vyvoje, nebo se pouziji az po jeho skonceni? Pokud to prvni, hrozi riziko, ze napisete program ne tak, aby byl spravny, ale aby prosel testy.

Mimochodem, extremni pripady a vadne vstupy jsou prave ty situace, kde je IMHO vhodnejsi assert. Nerikam, ze by se to nemelo testovat, jen ze mi prijde napsat tam assert jako ucinnejsi metoda nez napsat na to test. Samozrejme zalezi na tom, jak to podporuji nastroje - me pripada podpora assertu v modernich jazycich dost nedostatecna, spis se resi prave to TDD, coz mi prijde tak trochu krok stranou (o tom, ze treba Java nepodporuje metaprogramovani vubec - a vhodna abstrakce je nejucinnejsi forma predchazeni chybam - nemluve; a jeste to dost lidi povazuje za vyhodu).

[Reklama]

[nm]

Nevim sice co je assertion, jeste jsem to nepochopil. Ale asi zalezi na tom, jak kvalitne se ty testy napisou. To ale taky jeste neni uplne ono. Protoze v tom odkazu na Wikipedii je jasne patrny, ze i nejlepe napsane testy muzou v jistych pripadech selhat.

Podle mne je to podobny tomu, jako kdyz lidi delaji pristani modulu s posadku na Mesic v laboratornich podminkach. To jsou taky takove testy (at uz primo simulace pristani nebo matematicke dokazani spravnosti vypoctu), ale neznamena to, ze jsou 100%-ni. Nejlepsim testem je fakt s tim modulem na tom Mesici pristat a mit s sebou vsechny merici pristroje, ktery kontrolujou spravnost toho pristani a vyhodnocujou chyby. Ale ani tenkrat to jeste neznamena 100%ni vyhru. Tech pristani by se musela udelat cela rada. A porad se jeste vyskytne chyba v dalsim pristani. To bysme museli znat 100%-ne vesmirnou fyziku a buhvi co jeste.

Tudiz testy samozreme teda ano. Plati pro ne asi podobny pravidlo, jako pro programovani. Pokud si myslis ze je software bez chyb, vzdycky tam nejaka chyba jeste je.

Otazka ale zrejme zni, co je lepsi - jestli assert nebo test. Vypada to, ze kazdy z nich je dobry na neco. Takze asi by bylo dobry rict, na co je perfektni assert a na co je naopak vynikajici test, ci TDD?

[JS]

Nevim sice co je assertion, jeste jsem to nepochopil. Ale asi zalezi na tom, jak kvalitne se ty testy napisou. To ale taky jeste neni uplne ono. Protoze v tom odkazu na Wikipedii je jasne patrny, ze i nejlepe napsane testy muzou v jistych pripadech selhat.

Assert je kontrola, ze je v danem miste/okamziku behu programu splnena nejaka podminka (viz C makro assert). Muzou byt pouzite jak pri ladeni, tak v realnem nasazeni (zalezi na tom, jak moc chcete mit program odolny vuci chybam navrhu vs. efektivitu zpracovani/psani).

Vyhoda assertu je, ze testuji neomezenou mnozinu pripadu. Priklad - dejme tomu funkce f(a,b) dvou parametru, kde a nesmi byt 0. Test zkousi konkretni dvojici hodnot a,b a porovnava vysledek. Assert testuje primo, zda a je nerovno 0. Takze assert selze pro libovolnou hodnotu b.

Na druhou stranu, nevyhoda assertu je, ze tezko muzete pomoci assertu overit vysledek funkce samotne, aniz byste zduplikovali jeji funkcionalitu. A take ty nastroje - uz to tu nekdo zminoval, ale to je spis prakticky problem.

U testovani je to vzdycky o tom, jak moc automaticke chcete testy mit. Uplne automaticke testy s totalnim pokrytim znamenaji fakticky napsat aplikaci znovu jeste jednou a porovnavat vysledek s tou puvodni. Pokud se spokojite s necim mensim (jako ze v praxi temer vzdycky :-)), pak vam staci otestovat omezenou mnozinu pripadu.

[Franta]

Vyhoda assertu je, ze testuji neomezenou mnozinu pripadu. Priklad - dejme tomu funkce f(a,b) dvou parametru, kde a nesmi byt 0. Test zkousi konkretni dvojici hodnot a,b a porovnava vysledek. Assert testuje primo, zda a je nerovno 0. Takze assert selze pro libovolnou hodnotu b.

Tady se právě dost liší zaměření jednotkových testů a assertů uvnitř kódu. Zatímco test bude kontrolovat hlavně to, že funkce bude pracovat správně na svém definičním oboru, assert kontroluje hlavně to, že odjinud nevolám tuto funkci se špatným vstupem – což naopak jednotkové testy nekontrolují a selžou až v případě, že selže ta volaná funkce.

[JS]

Zatímco test bude kontrolovat hlavně to, že funkce bude pracovat správně na svém definičním oboru, assert kontroluje hlavně to, že odjinud nevolám tuto funkci se špatným vstupem – což naopak jednotkové testy nekontrolují a selžou až v případě, že selže ta volaná funkce.

Nemusi byt pravda. Assert muze take kontrolovat obor hodnot funkce, invarianty datovych struktur, zda nedoslo k preteceni atd., nejenom predavane parametry.

[Franta]

Může být. Ale pak je trochu otázka, jestli ta funkce není moc dlouhá/komplexní – když jde někam doprostřed vložit assert, který zkontroluje mezivýsledek, možná by to mohly být dvě funkce, kde jedna vytváří vstup pro druhou (neříkám, že vždy).

BTW: když píšeš o assertech, tak to myslíš tak, že se použijí ve fázi testování (program se bude pouštět na testovacích datech), nebo že budou zapnuté i normálně v ostrém provozu?

[ava]

Podle me zakladni rozdil mezi asserty a unit testy je v tom, ze asserty odhali pripadne chyby az pri behu programu, zatimco unit testy to umoznuji v podstate kdykoliv se rozhodnu zjistit si, zda prochazeji - kdyz neco "opravim", zmenim, vymenim behove prostredi, knihovny, atp... Unit testy pustim pri vyvoji klidne 20x za hodinu. S asserty musim pustit samotny testovany program, a pokud mozno jej pri behu donutit projit vetve, ktere asserty obsahuji, to proste zdrzuje a neni to spolehlive. Tim nerikam ze asserty nemaji sve pouziti, prinejmensim mohou usnadnit hledani chyb a take castecne dokumentuji definicni obor prijimanych parametru a obor navratovych hodnot funkci, ale ty ctyri veci co jsem zminoval ve svem predchozim prispevku

 - pomoc pri navrhu kodu, lepsi rozmysleni architektury a zpusobu pouziti
 - nahrada rucniho testovani, opakovatelnost testu, + jak tu nekdo zminoval, zajisteni ze jiz jednou opravene chyby se nebudou vracet
 - vetsi duvera ve vlastni kod, obzvlaste pri refaktoringu, optimalizacich, upgrade pouzitych knihoven
 - vzdy up-to-date dokumentace s priklady k pouzivani testovaneho kodu

proste nemohou asserty nahradit. Vyznam kazdeho je jinde.

[podlesh]

Pokud chci mit pokryto automatizovanymi testy, musi se tyto testy napsat, to je asi jasne. TDD je metodika, ve ktere se zjednodusene receno nejprve pripravi testy a pak se  implementuje.

Jadro naseho sporu je v tom, jak se TDD stavi k tomuto: http://en.wikipedia.org/wiki/Testing_hypotheses_suggested_by_the_data (Statistiku moc neznam, jen vim, ze ten problem existuje a je treba dat si na nej bacha.) Tedy, jinak receno, jsou ty testy dostupne neomezene behem vyvoje, nebo se pouziji az po jeho skonceni? Pokud to prvni, hrozi riziko, ze napisete program ne tak, aby byl spravny, ale aby prosel testy.

To není riziko, to je v jistém smyslu záměr. Tyto testy (v TDD) totiž neslouží primárně jako otestování implementace, ale jako definice s dokumentace sémantiky (ovšem udržovaná tak aby odpovídala reálnému stavu, což u "papírové" dokumentace nelze).

Pokusím se to demonstrovat na jednoduchém ilustračním příkladu: píšeme funkci která vypočítá artimetický průměr seznamu čísel. API je asi celkem jasné. Do testu napíšu několik jednoduchých případů (jeden prvek, několik prvků), v podstatě jen jako náhradu read-eval-print, to není zas tak důležité. Důležitý je speciální případ: co když jako parametr předám prázdný seznam? Záleží na návrhu API, buď to může být akceptovaný parametr a výsledkem bude NaN (nebo Inf?), v takovém případě se do testu doplní patřičný check (a assert tady nemá smysl). Jiné pojetí je takové, že prázdný seznam není platná vstupní hodnota a pokud o zavolání skončí s výjimkou / assertem. Pak do testu doplním check, který mi otestuje že tam ten assert je a má správnou podmínku. Pokud v testu není ani jedna ze těchto možností, tak je to špatné - po roce už nikdo nebude vědět, zda je prázdný seznam opravdu správný parametr nebo zda je chybějící assert bugem.

O čem že měl být ten spor?

[nm]

O čem že měl být ten spor?

Spor byl o prednostech assertu oproti testum.

JS - je zastance vyuzivani abstrakce pri programovani + assertu a tvrdi, ze testy jsou platne pro konecnou mnozinu dat (oproti assertum, ktere plati pro nekonecnou mnozinu dat). Tim padem TDD, podle nej, porusuje zasadu "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 ...

Franta - neni skalni priznivec TDD, ale zastava se testu, ktery dokaze pokryt to, na co je podle nej assert, nevyhodny...

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í).

Zda se tedy, ze assert je vyhodny tam, kde jsou slabe stranky testu a test je vyhodny tam, kde by pouziti assertu cinilo vetsi problem nez pouziti testu. Oba dva tedy maji sve vyhody a nevyhody. Takze me zajimalo, jake jsou vyhody assertu (kde je ho lepsi pouzit) a jake jsou vyhody testu.

Osobne bych se ale vratil k samotnemu TDD (Vyvoji rizenem testy) a jeho pouziti. Protoze se zda, ze testy jsou potreba, bud jako TDD nebo samostatne testy. Dovolil bych si diskusi tedy rozsirit i o dalsi metody testovani softwaru (napr. assert). Takze moje otazka zni:

Jaka je praxe v pouzivani testovacich metod pri programovani v praci (praxi)? A jake testovani pouzivate pri domacim programovani?

[JS]

To není riziko, to je v jistém smyslu záměr. Tyto testy (v TDD) totiž neslouží primárně jako otestování implementace, ale jako definice s dokumentace sémantiky (ovšem udržovaná tak aby odpovídala reálnému stavu, což u "papírové" dokumentace nelze).

Pokud je to skutecne tak, pak mi TDD prijde tedy pekne padle na hlavu. Dokumentace, ktera v realu testuje semantiku je prave ten assert. Vy neverite programatorovi, ze tam napise assert, ale verite, ze si na ten specialni pripad napise test. Ja budu radsi, kdyz tam da ten assert, at je jasne, jak to ma byt, a nemusime hadat z testu (to dalsi, testovat assert mi prijde uz uplne ujete, ale to spis z praktickych duvodu). Hezky je ten rozdil prave videt na pripadu funkce 2 parametru, kde jeden nesmi byt nula - tam zadnou konecnou mnozinu dvojic parametru nemuzete prokazat, ze jeden z parametru ma byt nenulovy na konecne mnozine.

Svym zpusobem mam pro to pochopeni. Lepsi nastroje existuji na TDD a asserty moc ne (nebo jeho bratricka design by contract). Ale vydavat to za vyhodu? Proc mi to jen pripomina tento clanek: http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/

[Mirek Prýmek]

Dokumentace, ktera v realu testuje semantiku je prave ten assert.

Ale nemůže otestovat všechno.

Už to tady zaznělo: jak pomocí assertu otestuju, že funkce při nulovém argumentu vyhodí konkrétní výjimku s konkrétními daty?