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

[ava]

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/

Me tedy prijde, ze z tebe mluvi totalni nepochopeni toho, co to vlastne Unit testy jsou.

Unit test ti overuje ***PRI VYVOJI***, zda je tvoje implementace funkce pro pocitani prumeru kolekce cisel korektni (pro [1, 2, 3] vraci 2) a zaroven specifikuje, jak se vlastne ma chovat v mene zjevnych pripadech (ma pro prazdny seznam vyhodit vyjimku? Vratit NaN?)

Assert overuje, zda se pri vykonavani funkce ***PRI BEHU PROGRAMU*** nevyskytl nejaky nepovoleny stav, nejcasteji zda funkce nebyla zavolana s neplatnymi parametry (napr. pokud podle specifikace nema byt mozne funkci pro pocitani prumeru predat prazdnou kolekci, hodis tam precondition assert, unit testem si pak muzes overit, ze funkce podle ocekavani pri zavolani s prazdnym seznamem skutecne vrhne assertovou vyjimku). Pokud ovsem specifikace napriklad prikazuje vratit pro prazdny seznam NaN, zadny assert ti zde nepomuze - pradny seznam je podle takoveto specifikace platna hodnota, pro kterou se vrati definovany vysledek. Ze se tak funkce skutecne chova ti jiz pri vyvoji umoznuje overit unit test.

Vetu s funkci dvou parametru, kde jeden ma byt nenulovy, jsem nepochopil. Nerozumim tomu, jak lze "prokazat ze neco ma byt nejake". Hezci priklad mi prijde prave ten s funkci pro pocitani prumeru, ktera bere jeden parametr, kolekci cisel.

Co ti na Unit testech ted prijde padle na hlavu? Mj. odkazuji na sve predchozi prispevky, kde jsem zminil i dalsi vyhody unit testu. Netvrdim ze jsou vselek a mely by se pouzivat uplne vsude, ale po trosce praxe (jako vse v programovani je treba si je nejprve osahat na nejakem vhodnem projektiku) je podle me clovek nemuze alespon v nekterych pripadech neocenit.

[Reklama]

[JS]

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?

Ano, tohle narazi na limity assertu v mnoha jazycich (napriklad v Common Lispu by makro na takovy assert nebyl problem vytvorit). Proto rikam, ze nemaji takovou podporu v jazycich jako testy, a to je skoda! Protoze jsou obecnejsi.. Ale principialne v tom problem neni - neni problem mit assert, ktery otestuje soucasne vstup a vystup z funkce (vyjimka je jen specialni druh navratove hodnoty).

Druha vec je, ze existuji ruzne druhy chyb. Ja bych treba testovani toho, zda vyjimka vyhodi konkretni (nejspis ladici) data pri chybe povazoval za zbytecne. To uz mi pripada jako testovani kompilatoru. Nakonec se na neco spolehnout musite, a pokud ne, eventualne skoncite tak, ze napisete v podstate vsechno 2x (taky moznost, nic proti, ale je to tradeoff).

[podlesh]

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

Tak znova: co když tam ten assert být nemá? Jistě, pokud bych měl nástroj ("nonassert"), tak by to šlo... ale výsledek pak bude stejný.

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.

Tato věta sice není zcela pochopitelná, ale to je jedno. Já nechci prokazovat, že parametr není nenulový - já chci prokazovat, že je taková situace ošetřena definovaným způsobem.

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?

Jistě, TDD je rezignace na implementaci "design by contract" pomocí silného typování. To je důvod proč vzniklo a je klíčové v jyzacích jako je smalltalk, ruby, python.

Proc mi to jen pripomina tento clanek: http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/

Protože je tam zmíněna základní odpověď:  they are mainly about achieving software quality, not correctness

Celé hledání jakéhosi rozporu mezi asserty a unit testy je prostě nesmyslné.

[JS]

Me tedy prijde, ze z tebe mluvi totalni nepochopeni toho, co to vlastne Unit testy jsou.

Nemam nic proti unit testum, proti cemu namitam je:

- Jejich pouzivani tam, kde jsou asserty jasne lepsi (jako treba u tech null situaci). A nebo v situacich, kde by bylo lepe zvolit dalsi abstrakci. Napriklad na overeni toho, zda funkce vraci spravne debug data. Idealni by bylo mit abstrakci, ktera toto zajistuje napric celou aplikaci; tim se zaruci, ze se vykonava stejny kod ve vsech situacich. Proste jsem pro predchazeni chybam nez jejich hledani pomoci testu.

- Jejich pouzivani namisto specifikace (viz niz).

- Vyvijeni funkci tak, aby prosly unit testy, a nikoli tak, ze se napise funkce a testy zvlast a pak se to otestuje. Proste pri vyvoji by se melo dbat na to, abychom nenapsali funkci, ktera sice projde testy, ale je vnitrne logicky zcela nesmyslna. Toho se obavam u filozofie TDD, i kdyz je mi jasne, ze to kazdy chape trochu jinak.

Asserty se nemusi nutne testovat pri behu - to je Cckove omezene chapani - svym zpusobem je formou assertu i staticka typova kontrola.

Vetu s funkci dvou parametru, kde jeden ma byt nenulovy, jsem nepochopil. Nerozumim tomu, jak lze "prokazat ze neco ma byt nejake". Hezci priklad mi prijde prave ten s funkci pro pocitani prumeru, ktera bere jeden parametr, kolekci cisel.

Protoze ten muj argument na funkci s jednim parametrem nefunguje. :-) Dejme tomu mam funkci na deleni dvou cisel div(a,b). Muzu otestovat co se stane div(1,1), div(2,0), div(50,3), div(0,7), div(0,0). Ale fakt, ze div(2,0) a div(0,0) ma podle testu selhat, nevypovida o tom, ze div(a,0) ma selhat pro libovolne a. Tohle testuje assert, protoze to je podminka na nekonecnou (nebo alespon neprakticky velkou) mnozinu pripadu. Takze jako specifikace jsou testy nedostatecne.

[podlesh]

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?

Ano, tohle narazi na limity assertu v mnoha jazycich (napriklad v Common Lispu by makro na takovy assert nebyl problem vytvorit). Proto rikam, ze nemaji takovou podporu v jazycich jako testy, a to je skoda! Protoze jsou obecnejsi.. Ale principialne v tom problem neni - neni problem mit assert, ktery otestuje soucasne vstup a vystup z funkce (vyjimka je jen specialni druh navratove hodnoty).

Tak, a máme unit test, i když přímo v kódu, protože máme lepší nástroje a nemusíme je oddělovat. Pěkné. Klasiká metadiskuse "všechno je blbost, protože v Lispu to lze udělat také a nazvat to jinak"

[Reklama]

[JS]

Tak znova: co když tam ten assert být nemá? Jistě, pokud bych měl nástroj ("nonassert"), tak by to šlo... ale výsledek pak bude stejný.

Co kdyz bude specifikace spatne? Budete delat specifikaci specifikace, protoze se nekdo pri psani specifikace mohl splest? Nekde to musite utnout, a konstatovat, ze tohle je to, co chcete. Ze to narazi na limit programovacich jazyku rikam od zacatku.

Tato věta sice není zcela pochopitelná, ale to je jedno. Já nechci prokazovat, že parametr není nenulový - já chci prokazovat, že je taková situace ošetřena definovaným způsobem.

A co takhle mit abstrakci, ktera to osetruje, a o ktere vime, ze uz funguje? Nebylo by to snazsi? Zase, od urcite chvile prestavate testovat program a zacinate testovat kompilator.

Protože je tam zmíněna základní odpověď:  they are mainly about achieving software quality, not correctness

No, a ja si proste myslim, ze nejdriv bychom se meli pokusit o tu korektnost (tedy pouzivat asserty a abstrakce) a pak az teprve o tu "kvalitu" (ve skutecnosti to prvni v mnohem postihuje to druhe). TDD dava prednost tomu druhemu na ukor spravnosti, a i kdyz mam jiste uvahy v tomto smeru, nepovazuji tento pristup obecne za spravny.

[JS]

Tak, a máme unit test, i když přímo v kódu, protože máme lepší nástroje a nemusíme je oddělovat. Pěkné. Klasiká metadiskuse "všechno je blbost, protože v Lispu to lze udělat také a nazvat to jinak"

Ne, to je nepochopeni. S tim oddelovanim je to syntakticka zalezitost (a take vec vkusu - me treba prijde prakticke oboji). Lisp davam jako priklad, protoze je to jazyk, ktery takovou vec umoznuje postavit bez zmen v syntaxi (i kdyz co je v pripade Lispu vlastne syntax je otazka :-)). Jak to ovsem oddelit/schovat je zalezitost nastroju, ktere pro asserty zatim moc neexistuji, pro testy ano.

[podlesh]

Co kdyz bude specifikace spatne? Budete delat specifikaci specifikace, protoze se nekdo pri psani specifikace mohl splest? Nekde to musite utnout, a konstatovat, ze tohle je to, co chcete. Ze to narazi na limit programovacich jazyku rikam od zacatku.

Tak znova a znova: toto je právě to utnutí. Zda je specifikace špatně nebo neřešíme. Důležité je, že víme jaká je, že víme co autor chtěl. Jistě, není to moc a mohou být efektivnější způsoby...

A co takhle mit abstrakci, ktera to osetruje, a o ktere vime, ze uz funguje? Nebylo by to snazsi? Zase, od urcite chvile prestavate testovat program a zacinate testovat kompilator.

Jistě že by to bylo snazší. A ano, je nutné stanovit nějakou hranici. A ano, možnosti jsou omezené, podle toho jaké mám nástroje. V určitém okamžiku (který leckdy nastane i okamžitě) se už nevyplatí. Není potřeba snažit se o absolutní dokonalost, je to jen řemeslnický nástroj.

Protože je tam zmíněna základní odpověď:  they are mainly about achieving software quality, not correctness

No, a ja si proste myslim, ze nejdriv bychom se meli pokusit o tu korektnost (tedy pouzivat asserty a abstrakce) a pak az teprve o tu "kvalitu" (ve skutecnosti to prvni v mnohem postihuje to druhe). TDD dava prednost tomu druhemu na ukor spravnosti, a i kdyz mam jiste uvahy v tomto smeru, nepovazuji tento pristup obecne za spravny.

S tou první větou se dá asi jen souhlasit, zase netuším kdo má jako zastávat opačný názor.

Druhá věta: citation needed! Já tvrdím že TDD je jen doplněk, který se s používám assertů a abstrakcí (a mnoha dalšími věcmi) kombinuje (částečně překrývá). Přínosy jsou, samozřejmě, omezené a hodně závisí na dostupných nástrojích. Popularita pak může záviset na různých věcech: v některých jazycích se uchytil hlavně kvůli chybějící typové kontrole, jinde získal popularitu kvůli chybějící read-eval-print loop, v "agilním hnutí" pak kvůli ulehčení problému se synchronizací dokumentace/specifikace (aneb "programování ve wordu").

Problém samozřejmě je, pokud se někdo na něco upne a nevidí okolí. These is no silver bullet...

[JS]

Druhá věta: citation needed! Já tvrdím že TDD je jen doplněk, který se s používám assertů a abstrakcí (a mnoha dalšími věcmi) kombinuje (částečně překrývá).

Pokud vnimas TDD takto, tak zadna citace neni potreba. To spolu v podstate souhlasime (i kdyz ja bych testy volil az na poslednim miste). Ale to neni to, co tu tvrdili jini lide - takze zalezi, co se pod TDD chape. Nekdo tu psal, ze TDD dovoluje, aby testy slouzily jako specifikace. To mi prijde spatne.

Take mi prijde spatny pristup, kdy napisu kod, ktery mi neni 100% jasny (tedy nemam v hlave formalizovanou jeho spravnost), napriklad, nevim, proc se dela nejaky prikaz, ale protoze projde testy, prohlasim ho za spravny. Pokud je toto TDD (nebo ho tak nekdo vnima), mam s tim problem. Protoze to je presne to, na co narazim odkazem na statistiku.

Jinak unit testy jsou tu uz desitky let, to neni zadna novinka. Takze co noveho prinasi TDD? Zda se, ze na to kazdy ma jiny nazor.

[ava]

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?

Ano, tohle narazi na limity assertu v mnoha jazycich (napriklad v Common Lispu by makro na takovy assert nebyl problem vytvorit). Proto rikam, ze nemaji takovou podporu v jazycich jako testy, a to je skoda! Protoze jsou obecnejsi.. Ale principialne v tom problem neni - neni problem mit assert, ktery otestuje soucasne vstup a vystup z funkce (vyjimka je jen specialni druh navratove hodnoty).

Tohle je podle me principialni problem, se kterym ti Common Lisp nepomuze. Assert nekontroluje chovani, ale stav. Stejne tak nesouhlasim s tvym tvrzenim, ze staticka typova kontrola je forma assertu. Staticka typova kontrola probiha pri prekladu, asserty se kontroluji za behu. To je take zasadni rozdil (proto jsem to v predchozim prispevku psal kapitalkami a jeste uzavrel do hvezdicek) oproti unit testum, ktere se neprojevuji pri samotnem behu programu, ale poustis je zvlast. Myslim ze moje chapani assertu je konzistentni s http://en.wikipedia.org/wiki/Assert , pokud ty osobne vnimas asserty nejak jinak, nasli jsme asi jadro nedorozumeni.

[JS]

Myslim ze moje chapani assertu je konzistentni s http://en.wikipedia.org/wiki/Assert , pokud ty osobne vnimas asserty nejak jinak, nasli jsme asi jadro nedorozumeni.

Nevim, me prijde, ze ten clanek oznacuje za asserty i takove, ktere se overuji jen pri prekladu. Kazdopadne, i kdybychom pripustili jen tu runtime definici assertu, tak jaky je rozdil mezi testem a assertem? V obou pripadech musi testovany kod bezet, aby bylo mozne ho overit; a u nekterych assertu je mozne je nechat je z kodu pozdeji automaticky vypustit.

[Mirek Prýmek]

Ano, tohle narazi na limity assertu v mnoha jazycich (napriklad v Common Lispu by makro na takovy assert nebyl problem vytvorit). Proto rikam, ze nemaji takovou podporu v jazycich jako testy, a to je skoda!

V těch obecných řečech nějak ztrácím představu, jak by to mělo v praxi vypadat. Snad ne promatkupřírodu takhle?!

Kód: [Vybrat]

def funkce(a):
   if a==0:
      t = NejakaVypecenaVyjimka()
      assert(a==0 and isinstance(t,NejakaVypecenaVyjimka))
      throw(t)


Protoze jsou obecnejsi..

Jak se to veme... Pokud mám asserty, které v release buildu vypnu, tak jsem pomocí nic reálně otestoval stejně jenom nějakou podmnožinu vstupů a výstupů - konkrétně takové, které vznikly při testování před releasem. V provozu potom stejně můžou vzniknout situace, který jsem neotestoval.

Pokud by měl být assert opravdu obecný, musel by být na vyšší úrovní - testovat, že taková hodnota tam z principu být nemůže a ne jenom to, že v tomto konkrétním běhu programu tam aktuálně není.

[ava]

JS: Super, myslim ze i kdyz se budeme bavit jen o runtime definici assertu, dojdeme k uzitecnym zaverum. Bez ztraty obecnosti budu hovorit o testovani jedine funkce, muzeme si predstavit napriklad tu co pocita prumer prvku ciselne kolekce.

Je samozrejme pravda, ze v obou pripadech musim testovany kod spustit. Lisi se ovsem
 - jak jej spoustim
 - co vlastne overuji

Unit testy:

 - spousteni: Kazdy jeden unittest je mozne vnimat jako miniprogramek, ktery skutecne spusti testovanou funkci s nejakymi vzorovymi daty, a overi, ze funkce vrati ocekavany vysledek. Diky integraci IDE a ruznych *unit knihoven, ktere usnadnuji psani unit testu, se pri psani testu vetsinou mohu soustredit primo na volani funkce a overovani bez nejakeho balastu jako je definice main funkce apod., at uz testuji ve smalltalku nebo v C. IDE mi vetsinou nabizi tlacitko, ktere spusti bud vsechny testy pro projekt, nebo testy ktere souvisi s kodem ktery prave upravuji, nebo napr. testy, ktere naposledy neprosly. Ve smalltalku je tak spusteni, provedeni a zobrazeni vysledku treba i nekolika set dobre napsanych testu otazka nekolika vterin.

- co overuji: Ze funkce se ocekavane chova pro vzorova data (tj. pro platne hodnoty vraci korektni vysledky, pro neplatne hodnoty napr. hodi AssertionError, DivisionByZero, podle specifikace), tedy v podstate spravnost implementace. Samozrejme nemohu pokryt celou mnozinu vstupnich hodnot, ale uz tak je to neco, co mi pouhe asserty vubec neumozni, a pri vhodnem vyberu testovacich dat (ten zavisi hlavne na intuici programatora - je potreba si uvedomit, ze testy pisu pro svoje vlastni dobro, a proto se je pokousim napsat tak, aby pokryly prave ty moznosti kde treba tusim nejakou zradu nebo problemy v implementaci), vyrazne zvednou duveru v to, ze testovany kod je spravne.

Asserty:

- spousteni: To, ze vlozim nejaky runtime assert do tela nejake funkce, nijak nesouvisi s tim, jak bude tato funkce volana. Pokud jde o knihovni funkci, je treba zrejme napsat nejaky testovaci program, ktery funkci pouziva (pokud pobezi automatizovane bez uzivatelskeho vstupu, jedna se v podstate o unit test), pripadne, pokud knihovnu pouziji rovnou v nejakem programu, tak v nem klikam, dokud jako programator znaly vnitrnosti nezpusobim domnele vyvolani testovane funkce, a kdyz to nespadne, doufam ze je to v poradku. Treba se tam ovsem nedoklikam ja ale az zakaznik, nebo se tam doklikam, o mesic pozdeji funkci "chytre" zoptimalizuji protoze profiler mi ukazal ze je to bottleneck, a budu zase dumat jak si overit ze jsem neudelal botu.

- co overuji: Ze stav parametru, dosazitelnych promennych, navratove hodnoty atp. je pri konkretnim volani platny. Vicemene neoveruji, zda se funkce chova podle specifikace.

[JS]

JS: Super, myslim ze i kdyz se budeme bavit jen o runtime definici assertu, dojdeme k uzitecnym zaverum. Bez ztraty obecnosti budu hovorit o testovani jedine funkce, muzeme si predstavit napriklad tu co pocita prumer prvku ciselne kolekce.

To je vsechno sice hezke, ale kde je tvoje pointa a jak to souvisi s TDD? Vsechno, co jsi rekl, jsem uz naznacoval vys v diskusi. Nejsem proti unit testum, jsem proti urcitemu zpusobu jejich pouzivani. A jasne jsem napsal, ze pokud toto je TDD, je to proste spatna metodologie.

[ava]

To je vsechno sice hezke, ale kde je tvoje pointa a jak to souvisi s TDD? Vsechno, co jsi rekl, jsem uz naznacoval vys v diskusi. Nejsem proti unit testum, jsem proti urcitemu zpusobu jejich pouzivani. A jasne jsem napsal, ze pokud toto je TDD, je to proste spatna metodologie.

Mym cilem nebyla pointa, jen diskuze s nekterymi tvymi nazory, s kterymi jsem nesouhlasil, a i kdyz tvrdis, ze vse co jsem rekl, jsi naznacoval jiz drive, nektere tve vyroky jsem puvodne vnimal jinak (:

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) Stale si myslis ze asserty dokazou nahradit unit testy?

Ja si myslim, ze pokud muzete zvolit mezi assertem a testem, assert je ucinnejsi. Podle me jsi srovnaval nesrovnatelne

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. Testy jsou dostupne behem vyvoje, pokud jsou spravne napsane, takove riziko je dost male. Programator, ktery by se tak choval, by byl sam proti sobe.

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. Opet, kazde slouzi k necemu jinemu. Psat testy na extremni pripady mi prijde v poradku.

Ano, tohle narazi na limity assertu v mnoha jazycich (napriklad v Common Lispu by makro na takovy assert nebyl problem vytvorit). Proto rikam, ze nemaji takovou podporu v jazycich jako testy, a to je skoda! Protoze jsou obecnejsi.. Ale principialne v tom problem neni - neni problem mit assert, ktery otestuje soucasne vstup a vystup z funkce (vyjimka je jen specialni druh navratove hodnoty). Takovy assert je problem, pokud netestuje stav, ale vztah vstupu a vystupu, pak se jedna o defacto duplikaci implementace funkce.

Nemam nic proti unit testum, proti cemu namitam je:

- Jejich pouzivani tam, kde jsou asserty jasne lepsi (jako treba u tech null situaci). A nebo v situacich, kde by bylo lepe zvolit dalsi abstrakci. opet, asserty zde nejsou lepsi, plni jinou ulohu, nedaji se s testy srovnat. Mmchd, pokud pises test, zda funkce assertuje neplatna data, nemusis testovat i presny format debugovacich vypisu, v praxi ti staci, ze jde o AssertionError, a na to uz unit test smysl napsat ma.

No, a ja si proste myslim, ze nejdriv bychom se meli pokusit o tu korektnost (tedy pouzivat asserty a abstrakce) a pak az teprve o tu "kvalitu" (ve skutecnosti to prvni v mnohem postihuje to druhe). TDD dava prednost tomu druhemu na ukor spravnosti, a i kdyz mam jiste uvahy v tomto smeru, nepovazuji tento pristup obecne za spravny. Asserty ti nijak nezajistuji korektnost, pokud tedy nepovazujes za korektni chovani to, ze kdyz se ti program dostane do nepovoleneho stavu, tak spadne. Ano, asi je to korektnejsi nez kdyby generoval nesmysly, ale ja si pod korektnim programem predstavim takovy, ktery se do nepovoleneho stavu nedostane.

Nekdo tu psal, ze TDD dovoluje, aby testy slouzily jako specifikace. To mi prijde spatne. Ne nutne, je videt ze nemas s unit testy zkusenost. Vyvoj programu pokryteho testy typicky vypada tak, ze hledam nejakou funkci, ktera by se mi mohla hodit, kdyz ji najdu, samozrejme me zajima jak presne se chova a jak ji pouzit. Najdu si jeji testy, a podle prikladu pouziti vetsinou velice dobre zjistim, jak reaguje na ocekavane a neocekavane vstupy. Nikdy se nestane, jako se to v praxi u textove dokumentaci casto stava, a velice obtizne tomu jde zabranit, ze by test neodpovidal realite. Jako specifikace tak mohou slouzit v praxi velice dobre, byt treba ta funkce nema rigorozne popsanou semantiku - zase si muzu byt jisty, ze ten popis neni obsolete, coz je castokrat horsi nez kdyby nebyl zadny.

A jak souvisi Unit testy s Test Driven Development? Mozna te zklamu, ale na to se mi nechce odpovidat :-) Jen jsem chvilku tahal pilku za unit testy (nj, rootovska captcha)