PCUT: knihovnička pro unit-testování C kódu (diskuse)

[retroslava]

hezký, určitě se bude hodit

[_]

Zajímavá motanice, jen co je pravda. Sice hack jako prase, ale drží se to vesměs v preprocesoru.

Chtělo by to skripty pro CMake nebo Autotools, generaci pkg-config souborů atp. Prostě udělat z toho normální projekt.

Zvážím použití, až se mi někdy přestane líbit LGPL v GLibu.

[:::]

Az budu mit trochu casu tak se na to podivam.

btw. kdyz uz jsme u toho testovani. Jakym zpusobem delate testy? Kolik testu? kolik casu tim stravite?

Ja se priznam ze s testovanim to neprehanim. Mam pocit ze kdybych chtel vsechno poradne otestovat tak tim stravim 15 x vic casu nez psanim kodu. A kdyz zacnu kod upravovat tak to bude jeste horsi...

Existuje najaka zazracna metoda jak vsechno otestovat a nestravit nad tim moc casu? (krome "delegovat to na nekoho" )

[zxtlpn]

Hm, nevim, já většinou asi píšu testy až potom, co něco poseru. Nebo když je nějakej kód choulostivej na drobný chyby.

[dad]

prvni c-program jsem napsal v roce 1982, tedy drive, nez byla vetsina zdejsich ctenaru na svete. To samozrejme neni zadna zasluha, nybrz nevyhoda, nebot jsem za ta leta vyvinul urcitou skepsi proti vsemu novemu. Jak sla leta, prichazely a odchazely programovaci jazyky, frameworky, paradigmata apod.

Kdyz tak dnes nahlednu do nejakeho odbornehio portalu, tak jedna z tech 'novych' veci (no ono je to asi 10 let stare) jsou prave ty unit-testy.

Rad bych se ted zeptal, jestli to opravdu je k necemu, nebo je to opet nejaky takovy nesmysl, ktery jen dela praci a uzitek zadny. Kdyz mluvim s nekym, kdo musi opravdu programovat a taky se tim zivit, tak ten zadne unit testy nedela. Zato lide zamestnani v tech velkych firmach, tam na to maj cela oddeleni. Schuzuji o tech testech, posilaji si pak maily o to, jak se o tech testech pobavili, co vsechno jak bude jeste vylepseno. Ale, nikdo z tech hlavounu s tim skutecne nedela. Kdyz se ptam, tak mi odpovedi, za na to maj pak 'lidi'.

Ja si myslim, ze cisar, ktery ma na sobe ty unit-test saty je nahy.

[Vojtěch Horký]

Můj osobní názor je, že smysl to má, ale nesmí se to přehánět. Pokud je v kódu chyba, můžu ji vyjádřit pomocí unit-testu a zabránit tak nějaké regresi. Pokud píšu kód, který počítá něco ohavného, možná se vyplatí připravit si nejdřív unit-test než pak hledat chybu v celém programu. A pokud vytvářím nový interface, je unit-test možnost, jak si vyzkoušet, že dává trochu smysl. IMHO pokud bude set-up funkce k němu vypadat blbě, tak je možná to rozhraní postavené na hlavu.

Rozhodně jsem ale proti názorům typu „tohle už není unit-test, na to máte použít jiný framework a úplně jiný způsob vyjádření“ apod. Nástroj použiju prostě proto, aby mi ulehčil ladění. Tečka. O což jsem se snažil i tady. Vnitřnosti jsou sice humus, ale navenek je to minimum kódu, co se dá rychle zapsat.

[Josef Kufner]

Testy jsou fajn, pokud píšeš knihovnu nebo relativně samostatnou komponentu. V takovém případě ti test slouží jednak jako ukázka použití, na kterou lze odkazovat z dokumentace. Ale pak ti také umožní si tu knihovnu odladit dřív, než napíšeš aplikaci okolo ní. Navíc některé hraniční případy se těžko simulují, pokud máš okolo moc dalšího kódu.

Na to je ale potřeba nástroj, který se snadno používá a samotný test je jednoduchý a snadno čitelný. Je to trošku paradox, ale samotné testování mi přijde jako ten méně zajímavý přínos ze psaní testů – důležitější jsou ukázky použití (dokumentace) a prostředí pro odladění knihovny.

[JS1]

Je mi to sice trochu proti srsti, je to jako smat se cizimu nestesti, ale nemuzu nevzpomenout na.

Jsem k TDD skepticky. K Unit Testum uz mene, myslim, ze funkcionalni programovani je na to idealni, ale bohuzel to take nepraktikuji tak, jak bych si pral (=> zkusenost s tim nemam).

Ale konceptualne nejsou unit testy vubec nove. Zejmena u programovacich jazyku a knihoven. Napriklad jisty interpretr Lispu z konce 80.let obsahuje unit testy (jako soucast dokumentace, pro kazdou funkci).

[podlesh]

Je mi to sice trochu proti srsti, je to jako smat se cizimu nestesti, ale nemuzu nevzpomenout na.

Velmi dobrý odkaz, dovoli bych si zdůraznit: they are mainly about achieving software quality, not correctness Což samozřejmě je i částečný důvod proč je to celé kontroverzní: celý pojem "quality" je ve výoji software a programování kontroverzní. Opravdoví programátoři takové hovadiny neřeší.

Jsem k TDD skepticky. K Unit Testum uz mene, myslim, ze funkcionalni programovani je na to idealni, ale bohuzel to take nepraktikuji tak, jak bych si pral (=> zkusenost s tim nemam).

Ale konceptualne nejsou unit testy vubec nove. Zejmena u programovacich jazyku a knihoven. Napriklad jisty interpretr Lispu z konce 80.let obsahuje unit testy (jako soucast dokumentace, pro kazdou funkci).

Ono je to koneckonců jen logickým rozšířením klasického bottom-up/REPL vývoje, akorát rozšířeného o reprodukovatelnost (a samozřejmě rozšířeného pro kompilované jazyky bez REPL). Takže druhým zdrojem kotroverze je bottom-up, který je nepřirozený pro všechny odchované na top-down. A samozřejmě vůbec nepomůže, když se někdo do "těch unit-testů" pustí aniž by si právě tohle uvědomil (viz můj příspěvek o cargo-cult).

[podlesh]

No, jak na to koukám, nějak moc se snažím psát rozumně a konstruktivně, to se mi vymstí....

[mich]

Opravdoví programátoři takové hovadiny neřeší.

Chápu to správně, že opravdoví programátoři neřeší kvalitu svého kódu?

[pavlix]

+1

[podlesh]

ne

[pavlix]

The alleged defining features of a "Real Programmer" are extremely subjective, differing with time and place, in the fashion of the "no true Scotsman" fallacy.

Ten no true scotsman tady sedí víc než kde jinde.

[deda.jabko]

Jsem k TDD skepticky. K Unit Testum uz mene

Ja bych sel klidne do vetsich extremu. TDD je blbost, na unit testy nedam dopustit.

Unit testy je potreba pouzivat s nejakym nastrojem na code coverage, jinak je to k nicemu. Zrovna vcera jsem diky kombinaci unit testu a code coverage objevil chybu, kterou bych normalne neobjevil jen s unit testama neobjevil.

Dalsi vyhoda unit-testu je v tom, ze kdyz je program pokryty unit testama, muze do programu zasahovat vic lidi, napr. zacinajici programator hned vi, ze nekde neco rozbil, cehoz by si bez toho mozna nevsiml.

myslim, ze funkcionalni programovani je na to idealni, ale bohuzel to take nepraktikuji tak, jak bych si pral

V posledni dobe jsem zacal programovat i v jave ,,funkcionalne'', resp. zacal jsem intenzivne pouzivat immutable objekty a prijde mi, ze se tim spousta veci znacne zjednodusila.

[mich]

+1. Podepisuju se pod celý příspěvek.

[pavlix]

Unit testy je potreba pouzivat s nejakym nastrojem na code coverage, jinak je to k nicemu.

To zní jako další vtip v diskuzi. Code coverage nástroje jsou příjemný bonus, když si chce člověk ušetřit práci s hledáním zjevně nepokrytých částí programu, víc od toho nejde čekat. Nedá se říct, že by coverage nástroje byly tou zásadní částí testování.

[deda.jabko]

když si chce člověk ušetřit práci s hledáním zjevně nepokrytých částí program

nesouhlasim, code coverage nastroje jsou vyborny nastroj, ktery dokaze upozornit na casti kodu, u kterych neni zjevne, zda jsou pokyte nebo ne

[pavlix]

To je právě ten cargo kult, o kterém tu už několik lidí psalo, tedy zaměňování nástroje s cílem. Pokrývání částí (skupin řádků) kódu je dobré tak maximálně ke splnění nějaké kvóty definované nějakým kravaťákem.

Pokud jde člověku například o odolnost vůči regresím (jeden z hlavních důvodů, proč testy zavádět), je potřeba pokrývat spíše funkcionalitu daného software a různé případy užití té funkcionality, než řádky kódu.

Nepokryté řádky kódu často prozradí nějakou zapomenutou nepokrytou funkcionalitu, ke které se tak člověk může vrátit než dojde k release s chybným chováním.

u kterych neni zjevne, zda jsou pokyte nebo ne

Moje zkušenost říká, že jsou coverage nástroje schopné odchytit nepozornost (proto ji taky zavádím) a tím to asi tak končí. U zbytku testování se bohužel musí přemýšlet, aby to mělo nějaký smysl.

Tedy pořád vidím coverage nástroje jako velmi milý bonus, nikoliv jako základní kámen testování.

[deda.jabko]

To je právě ten cargo kult, o kterém tu už několik lidí psalo, tedy zaměňování nástroje s cílem.

Kde zamenuju nastroj s cilem? Myslim, ze mi neco podsouvas. Mimochodem, vyse pisu, ze TDD je blbost (protoze IMHO testovani nemuze byt smyslem vyvoje softwaru.)

Pokrývání částí (skupin řádků) kódu je dobré tak maximálně ke splnění nějaké kvóty definované nějakým kravaťákem.

To je blbost. Uz mockrat me code coverage upozornil na to, ze test nestuje vsechny varianty, co muzou nastat.

je potřeba pokrývat spíše funkcionalitu daného software a různé případy užití té funkcionality, než řádky kódu.

Ale toto nejsou unit testy, o kterych si tu bavime! Smyslem unit testu je overit, ze zakladni kameny, na kterych stavis (metody, tridy), funguji tak, jak maji, nic vic, nic min.

Nepokryté řádky kódu často prozradí nějakou zapomenutou nepokrytou funkcionalitu,

Myslim, ze davas rovnost mezi unit testy a testovani obecne, pricemz to prvni je pouze podmnozinou druheho.

[pavlix]

Kde zamenuju nastroj s cilem? Myslim, ze mi neco podsouvas.

Možná je to jen můj dojem. Mám za to, že jsi tvrdil, že unit testy bez coverage nástrojů jsou k ničemu. Osobně si to vysvětluju tak, že považuješ line coverage za hlavní cíl unit testů, zatímco já osobně považuju coverage reporty za nástroj, který v některých případech upozorní, že jsem něco přehlédl. Samozřejmě jsem tě mohl pochopit špatně.

Mimochodem, vyse pisu, ze TDD je blbost

Vzhledem k tomu, že i TDD považuju pouze za nástroj, nedává mi smysl o něm tvrdit, že je to nesmysl, maximálně tak že bývá často nesmyslně používán, ale o kterém nástroji toto nelze říci.

(protoze IMHO testovani nemuze byt smyslem vyvoje softwaru.)

Nějak mi není jasná souvislost mezi faktem, že testování není smyslem vývoje, a smyslem či nesmyslem TDD.

Uz mockrat me code coverage upozornil na to, ze test nestuje vsechny varianty, co muzou nastat.

Mně párkrát taky, což jsem mimochodem psal v předchozím příspěvku.

Ale toto nejsou unit testy, o kterych si tu bavime! Smyslem unit testu je overit, ze zakladni kameny, na kterych stavis (metody, tridy), funguji tak, jak maji, nic vic, nic min.

Mám to chápat jako změnu názoru? Zvýrazněná část je totiž podstatou toho, co tu od začátku obhajuju.

Myslim, ze davas rovnost mezi unit testy a testovani obecne,

To je docela zajímavý pohled.

Testy s jemnější granularitou mají své výhody. Umožňují otestovat chování, které se ve větším celku zatím nepoužívá. Přesněji určují místo podezřelé z chyby. Poskytují ověřený příklad užití jednotlivých stavebních bloků. Dají se lépe svázat s vyřešenými chybami.

Nic z uvedého mě ale nevede k přehodnocení názoru, že smyslem testů s libovolnou granularitou je testovat funkcionalitu, nikoliv pokrývat řádky. Běžně v projektech nechávám nepokryté řádky, pokud neodhalí nepokrytou funcionalitu. Coverage nástroje typicky spouštím když začínám mít pocit, že mám funkcionalitu pokrytou a hledám v nich, jestli jsem něco nezapomněl. Tedy jako doplňkový, nikoliv klíčový, nástroj.

Můžeš tedy nějak rozvést, proč a v čem by měly být unit testy v tomto vnímány odlišně od všech ostatních testů (pokud ta hranice vůbec lze dobře definovat)?

[deda.jabko]

Osobně si to vysvětluju tak, že považuješ line coverage za hlavní cíl unit testů,

Vysvetlujes si to blbe. Bylo to mysleno tak, ze pokud mas testy a neprojedes to nastrojem na code coverage, tak nemas jistotu, jestli neco neprehledls, a to se stava dost casto. Navic v takove situaci muzes zit v blahove predstave, ze kdyz ta cast kodu prosla testy, tak by mela byt v poradku. Coz je snad jeste horsi, nez kdyby vubec testovana nebyla.

TDD považuju pouze za nástroj

Ted si odporujes. TDD dava jako hlavni smysl, aby program prosel testy, ... coz je presne to, proti cemus o prispevek vys brojils.

funguji tak, jak maji

Ja vubec zadne nazory nemenim. A hlavne vytrhavas veci z kontextu. Psal jsem smyslem unit testu je overit, ze zakladni kameny, na kterych stavis (metody, tridy), funguji tak, jak maji. A ty pises neco "je potřeba pokrývat spíše funkcionalitu daného software". Coz nejsou dve identicke veci.

Nic z uvedého mě ale nevede k přehodnocení názoru, že smyslem testů s libovolnou granularitou je testovat funkcionalitu, nikoliv pokrývat řádky.

A to jsem nekde tvrdil?

[Agent]

TDD dava jako hlavni smysl, aby program prosel testy

A tedy dělal to co měl, ne? Při vytváření testů si zároveň ujasňuji, upřesňuji funkcionalitu programu.

[xkucf03]

TDD dava jako hlavni smysl, aby program prosel test

Testy snad program musí projít i bez TDD, ne? Ale pointa TDD je v tom, že píšu nejdřív testy a až potom program.

[deda.jabko]

Ale pointa TDD je v tom, že píšu nejdřív testy a až potom program.

Pointa TDD je v tom, ze cely vyvojovy cyklus se prizpusobuje testovani. Coz muze mit pozitivni i negativni dusledky.

Priklad z jineho soudku. Nedavno mi jeden clovek rekl, ze smyslem cviceni na vysoke skole je prece, aby ziskal zapocet. To, ze by se mel neco naucit, je jen vedlejsi dusledek.[1] A tato zvracena logika je prave pouzita v TDD.

[1] V americe si na tom zalozila byznis spousta firem, ktere uci studenty techniky, jak projit testy typu SAT, GRE, aniz by jim davaly nejake hlubsi vedomosti.

[xkucf03]

Já to neobhajuji jen jsem chtěl upřesnit.

Ono TDD jsou dva druhy:

• Acceptance TDD
• Developer TDD

Tomu prvnímu se říká spíš BDD (Behavior-driven development) a když se mluví o TDD, myslí se tím spíš to druhé. A toto TDD staví na jednotkových testech – a jak jsem tu psal, tyto testy nesouvisí s požadavky zákazníků, jsou z tohoto pohledu irelevantní. Je to pomůcka pro vývojáře¹ nikoli nástroj k dosažení kvality z pohledu zákazníka. Přesně jak píšeš – když zaškrtáš správné odpovědi v testu nebo odpovíš na otázky učitele (každý semestr stejné) v ústní zkoušce a projdeš – tak moc to nevypovídá o tvých znalostech a o splnění cíle z pohledu zákazníka².

Že nějaká metoda vrací to, co si programátor (nebo i architekt nebo analytik) myslí, že by měla vracet není zárukou toho, že program jako celek bude dělat to, co požaduje zákazník. Míst, kde se to může vysrat³ je strašně moc a funkčnost jednotlivých jednotek (unit) prakticky nic neznamená – dokonce i nefunkční (neprocházející testem) jednotky můžou vést na dobrý výsledek (fungující celek – program). Buď proto, že v testu je chyba⁴ nebo proto, že je chyba na dvou místech a navzájem se vyruší a výsledek funguje (např. se hodnota někde blbě vynásobí dvěma a jinde zase blbě vydělí). Z tohoto pohledu dává větší smysl BDD a komplexnější testy (ne jednotkové), které ověřují funkci programu jako celku.

Ale ani tak bych to (Developer) TDD úplně nezavrhoval, dá se pro něj najít i smysluplné využití. Každopádně je to jen dílčí metodika nebo spíš bych řekl technika, která se použije v rámci jiné (všeobjímající) metodiky.

Jestli je to zvrácená logika je otázka. Občas se prý stane, že někdo v Indii napíše kód, který obsahuje pár IFů a vrací ty hodnoty, které od něj test očekává, aniž by plnil tu skutečnou funkci, kterou plnit má. Napsat dokonalý test, který by byl proti tomu imunní, prakticky nejde. Stejně se nakonec dělají revize kódu, ale je lepší mít kolegy, kteří se o takové podvody ani nebudou pokoušet. Ale v kultivovaném prostředí je to něco jiného a může to být k užitku – místo abys měl analýzu a v ní příklady jako text, tak můžeš rovnou dostat i testy – v podstatě je to ta samá informace, jen ve strojově čitelné a spustitelné podobě. Jak jsem tu někde psal – test jako forma komunikace (ne jako nástroj pro dosažení kvality).

_{[1] někdy i celkem užitečná, protože může např. usnadnit zadávání práce méně zkušeným kolegům
[2] kterým jsi tady vlastně ty a cílem je příprava na budoucí zaměstnání (pokud ti nejde jen o ten papír)
[3] volání těchto metod, chyby ve frameworcích a knihovnách třetích stran nebo nepochopené jejich API, špatná výchozí konfigurace a ukázkové soubory, špatné volby kompilátoru, špatně deklarované závislosti na jiných balíčcích, chyby v pomocných skriptech, nekompatibilita s verzí OS, jazykovou mutací nebo výchozím kódováním, špatná dokumentace atd.
[4] on i test je vlastně programem}

[podlesh]

Ja si myslim, ze cisar, ktery ma na sobe ty unit-test saty je nahy.

Existuje speciální termín který shrnuje celý problém: cargo-cult. Tato metafora se mi obzvláště líbí protože lze na ní krásně demostrovat bláhovost vášnivých disputací cargo-kultistů s cargo-ateisty.

Totéž platí i pro jiné kulty, jako jsou například design patterns či object-oriented.

[pavlix]

To je pravda. Mnohé koncepty, ze kterých věci jako OOP nebo TDD vycházejí, jsou v programování velmi přínosné a důležité. To je to cargo, tedy užitný náklad. Ve chvíli, kdy se reálné užití promění v uctívání, tak je výsledek dost divoký.

[pavlix]

Kdyz mluvim s nekym, kdo musi opravdu programovat a taky se tim zivit, tak ten zadne unit testy nedela.

To je pravda. Když totiž člověk dělá testy, tak to omezí množství chyb, které by pak mohl řešit a tím pádem se vlastně připravuje o práci ;).

Dnes a denně můžu srovnávat uživání testovaného i ne tak dobře testovaného software a sledovat další uživatele, jak při instalaci každé nové verze trnou, co všechno se rozbije. Někdy to vede až k tomu, že dávají přednost zakonzervovaným verzím s více či méně známými chybami než aby se nechali překvapit, kolik věcím jim zase přestane fungovat.

Ja si myslim, ze cisar, ktery ma na sobe ty unit-test saty je nahy.

To rozhodně. Testy jsou nástroj, nikoliv cíl a výsledek závisí na tom, jak se ten nástroj používá. Když vezmu do ruky kleště, tak to taky ze mě nedělá elektrikáře.

[xkucf03]

Dnes a denně můžu srovnávat uživání testovaného i ne tak dobře testovaného software a sledovat další uživatele, jak při instalaci každé nové verze trnou, co všechno se rozbije.

Mluvíš o jednotkových testech nebo o testech obecně?

[TM]

Dade, to co teď píšete je, sorry, děsná kravina.
Pokud děláte něco malého, UT možná nepotřebujete. V dobře vedeném velkém projektu jsou k nezaplacení.
Zkušenost z mojí praxe v projektech, psaných v C, C++ (embedded na 32 bitových mikrokontrolérech) jasně dokazuje, jak pozitivní vliv mají UT na výslednou kvalitu kódu, kolik zbytečných chyb díky nim vývojář odhalí ještě před tím než se to celé testuje v modelu a na reálném hw.
Fungování bez UT si nedovedu představit. V roce 1982 mně bylo 14, tedy vycoolovaný mlíčňák dnes fakt nejsem...

Samozřejmě je třeba UT psát podle specifikace, ne ho přizpůsobovat testovanému kódu(pak by to fakt k ničemu nebylo)

[xkucf03]

Pokud děláte něco malého, UT možná nepotřebujete. V dobře vedeném velkém projektu jsou k nezaplacení.

Ono nejde až tak o velikost projektu, jako spíš o to, co těmi jednotkovými testy pokrýváš. Když jsou to nějaké tvoje vlastní třídy/funkce, které přijímají a vracejí nějaké tvoje struktury nebo primitivní datové typy a mají uvnitř nějakou netriviální logiku (tzn. jednoduché rozhraní + složitý vnitřek), pak jednotkové testy dávají velký smysl a jsou hodně užitečné.

Pokud ale ten testovaný subjekt má spíše jednoduchou vnitřní logiku a ta složitost je v interakci s okolím (frameworky, knihovny, síťové protokoly, souborové formáty…) a ty tohle okolí v testech musíš simulovat, mockovat, tak ten smysl unit-testů je hodně malý a někdy i záporný (zbytečná práce). Nic ti nezaručí, že jsi ta složitá rozhraní nasimuloval správně a procházející unit-test nic neznamená – je to úplně odtržené od reality, ve které ten program pak bude fungovat. Jde např. o to, jak máš inicializovat okolní objekty, v jakém pořadí máš volat jejich metody, jaké jsou přípustné hodnoty (že jde např. někam podle signatury metody poslat String neznamená, že tam můžeš poslat jakýkoli String), jestli může být vstupem/výstupem i null nebo prázdná kolekce či řetězec nebo tam musí „něco“ být, jestli je bezpečné s tím pracovat z více vláken, za jakých okolností si z těch objektů můžeš vytáhnout určité vlastnosti a za jakých tam bude null nebo vyhodí výjimku atd. atd. Teoreticky bys měl mít dokonalou (aktuální a kompletní) dokumentaci/specifikaci všeho a měl bys být schopný podle toho to prostředí v testech nasimulovat – ale to by jednak dalo hodně práce (v podstatě bys ten okolní software musel napsat podruhé) a jednak ty tu dokonalou dokumentaci většinou nemáš.

[dad]

Dade, to co teď píšete je, sorry, děsná kravina.

to mi mrzi a ja se budu snazit, aby se to uz neopakovalo.

[Šangala]

Na světě jsem už byl, ale první program jsem napsal o pár let později (jen na kalkulačce) a první v C asi za 8 let.

A pro C++ mám vlastni řešení třída+preprocesor-macra (bohužel ne přímo thread-safe, ale používám to i v multi-thread) a ke každé třídě/jednotce, která má funkci knihovny vytvořím unit test (jednoduchým copy&paste a přepsání na dvou místech). A pak tam sjedu funkcionalitu, kterou stejně potřebuji odzkoušet a doplním s rozumem test limitních vstupů.

A takto to pro mě má okamžitý smysl už pro ověření funkčnosti(, stejně bych dělal nějaký malý main()), pak to má to smysl, že se to donutí lépe zamyslet nad limitami a rovnou je otestovat (- s rozumem), a má to smysl jako základ profilování, už tam odzkouším výkonově kritické chování (prostě to změřím a porovnám), dále to plní funkci doc-by-example, a pokud jsou třídy nějak provázané, tak při jakékoliv následné úpravě po projetí všech testů mám velmi slušnou šanci, že to nic nenabořilo (ano, měl bych ji mít už by-design, ale ne vše je křišťálově čisté a každé zadání i hned přesné).

A když mám použít nějakou knihovnu a žádně testy tam nejsou, tak přemýšlím, jestli autor vůbec ví jak se to chová, a pokud to ví autor, je to hezké, ale já si to musím ověřit a nějaké testíky smolím.

Podle mě, psát to na cokoliv včetně např. datové třídy, je úlet…

Přijde mi logické, že velká firmy a velké týmy na tom staví, je to hezký nástroj ke kontrole předávaných-sdílených kódů a může být super, když je (unit testy) navíc vytvoří někdo jiný, jen dle dokumentace.

[petr_p]

Když píše kód, který už nikdy neuvidíš, tak tě testy chyby příliš nevzrušují. Když ale děláš něco, co závisí na existuje v měnícím se prostředí, něco co se vyvíjí a udržuje, tak automatické testy jsou zatraceně dobrá věc. Snadno pak zjistíš, že se něco pokazilo. Často dříve než uživatelé. Příklad.

[rbt]

U projektu psanych v dynamicky typovanych jazycich jako python nebo ruby je to prakticky nutnost. Vyrostly kolem toho nastroje jako rspec, ktere tuhle nudnou a zdanlive neproduktivni praci brutalne zjednodusuji. Tady se tomu nevyhnou ani opravdovi programatori.

[xkucf03]

Ano i ne.

Jednotkové testy ti pomůžou při týmové práci, když potřebuješ rozdělit úkoly mezi lidi – testy jsou formou komunikace a umožňují vyvíjet část programu už ve chvíli, kdy k ní ještě neexistuje ten protikus. Nebo když kompilace celého programu, instalace a restart trvají dlouho, tak s jednotkovým testem si můžeš ladit nějakou malou část a pouštět si to pořád dokola, než to bude ok, a pak to teprve vyzkoušíš v rámci celku. Pak samozřejmě taky pomohou odhalit nějaké ty chyby, ale tuhle vlastnost bych nepřeceňoval (vzhledem k požadavkům zákazníka/uživatele jsou unit-testy irelevantní, mimoběžné – je to pomůcka pro vývojáře, ne nástroj pro dosažení kvality požadované zákazníkem).

A na druhou stranu: když se z toho stane dogma (100% pokrytí, unit-testovací fetišismus), tak spíš škodí. Taky můžou vést k iluzi „máme jednotkové testy → máme otestováno“ což je samozřejmě nesmysl (pokrytí testy a jejich průchod nevypovídá nic o kvalitě z pohledu zákazníka/požadavků).

[pavlix]

Věřím, že to, co píšeš, vychází ze tvých zkušeností. Už jenom proto, že se to s konkrétní podmnožinou mých zkušeností naprosto míjí.

Když odhlédneš od živnostenského či malofiremního dogmatu a dogmatu produktů pro koncové zákazníky, zjistíš, že existují případy, kdy jsou zákazníkem právě další vývojáři. A nemusí to být nutně platící vývojářská firma, ve větších celcích fungují i interní zákazníci, kteří se v mnohých případech projevují takřka totožně jako ti externí.

Když se navíc odpoutáš od firemního dogmatu, zvlášť v open source se to projevuje, o úspěchu projektu často rozhodují i další lidé než výše uvedení. Z hlediska vývojáře či vývojářského týmu je docela praktické takové lidi mezi zákazníky počítat taky.

pokrytí testy a jejich průchod nevypovídá nic o kvalitě z pohledu zákazníka/požadavků

Interní testování především není o průchodu ani o pokrytí, ale o tom, abysis u zákazníka neudělal ostudu, ať už kvůli tomu, že selhává zcela základní funcionalita a program nelze třeba ani předvést, nebo se ti třeba vrátí chyba, kterou jsi zákazníkovi slíbil vyřešit a teď to vypadá jako bys ji nevyřešil.

Na to jsou obecně vhodnější testy s hrubší granularitou než jsou funkce a třídy, ale neplatí to vždy. Někdy je dobré hrubším testem kontrolovat nějakou funkcionalitu a jemnějším testem kontrolovat třeba různé pluginy, které může zákazník použít a pro které nemáš třeba připravený setup, takže se nakonec dostaneš až na úroveň právě toho unit testu.

Především, už to někdo určitě psal, nemít chyby v novém kódu nebývá hlavní motivací psaní automatizovaných testů.

[xkucf03]

Přijde mi, že máš dost podivně definované pojmy (zákazník vs. uživatel vs. kolega; jednotkový test vs. automatizovaný test vs. testování obecně). Někdy se k tomu třeba rozepíšu trochu víc…

[pavlix]

Přijde mi, že máš dost podivně definované pojmy

Pojem interní zákazník se zavádí ve chvíli, kdy dotyční nejsou kolegové ve smyslu, že bysis s nimi mohl kdykoli sednout na oběd a domluvit se, ale z nějakého důvodu s tebou komunikují přes jejich a tvůj management a řeší se s nimi v podstatě stejné věci jako s externími zákazníky, pokud vynecháš obchodní stránku.

Uživatel knihovny je z mého pohledu ten, kdo knihovnu používá, tedy vývojář programového celku, který knihovnu linkuje. Máš na to nějaký jiný názor?

Jednotkové a automatizované testy máme předpokládám definované úplně stejně. Zbytečně se necháváš zmást (stejně jako deda.jabko) tím, že v některých případech vynáším obecnější tvrzení a tudíž v celku logicky použiju obecnější pojem.

Navíc nejsem ohledně testů dostatečně náboženský, takže se stává, že při testování stejných věcí volím mezi čistými jednotkovými testy a testy s libovolně hrubší granularitou, protože je pro mě z nějakého důvodu nepraktické snažit se funkce, třídy či moduly izolovat.

Může se tak stát, že úplně stejně napsaný testovací kód nesplňuje podmínky pro unit testing jen proto, že nemám namodelované prostředky, které daný modul používá. Pak se granularitou i záběrem jedná o integrační test toho modulu, který se ale při absenci jednotkového testu používá i k otestování modulu samotného.

[Josef Kufner]

Rozlišovat mezi unit testy a těmi ostatními testy mi také přijde zbytečné. Pokud chci otestovat modul, který je navázán na své okolí, stačí udělat dva testy. První otestuje okolí bez testovaného modulu (nebo jen s použitím triviální funkčnosti) a druhý to otestuje obojí. Pokud se vyskytne chyba v druhém testu, tak pokud prošel první, je to v modulu a pokud neprošel, je to v jeho okolí. Občas to nemusí být tak snadno oddělitelné, ale většinou to funguje dobře.

[pavlix]

Tak. Bylo by mi líto věnovat většinu času vymýšlením dokonalé metodologie jejímž jediným účelem je, abych nemusel při práci používat hlavu ;).

[xkucf03]

Co je interní zákazník, vím bohužel až moc dobře ale zpět k tématu. Když někdo používá tvoji knihovnu, nezajímají ho jednotkové testy, které ověřují funkčnost¹ nějakých interních jednotek zdrojáků (white box), jeho zajímají integrační/systémové testy, které k testovanému subjektu (knihovně) přistupují zvenku (black box) a ověřují implementaci API na základě nějakého kontraktu (specifikace). Pro něj je klíčové, aby se knihovna navenek chovala konzistentně (např. mezi verzemi nebo při změně okolního prostředí), ale vůbec ho nezajímá, jestli interní metoda/funkce např. xyz() schovaná kdesi uvnitř kódu knihovny vrací true nebo false.

Něco jiného je, když si ten člověk začne číst zdrojáky té knihovny a pocítí touhu tam něco změnit – pak mu jsou jednotkové testy k užitku – ovšem v tu chvíli je v úplně jiné roli: není to zákazník nebo uživatel, ale je to tvůj kolega – spolutvůrce toho softwaru (knihovny) a v této roli logicky jednotkové testy ocení. Po tom, co se dohodnete na začlenění jeho změn, může se zase přepnout do role uživatele a brát knihovnu zase jako černou skřínku odpovídající specifikaci a poskytující nějaké veřejné API. Ty role si můžeš přepnout klidně několikrát za den, ale to nic nemění na tom, že jednotkový test je zajímavý pro roli programátora/autora, nikoli pro uživatele/zákazníka.

Může nastat i specifický případ, kdy po tobě platící zákazník bude chtít jednotkové testy (a spoustu dalších věcí jako konvence, dokumentace atd.), protože chce převzít tvoje zdrojáky a pokračovat ve vývoji – ovšem to je taková hybridní role: zákazník/zaměstnavatel/uživatel/kolega/spoluautor a ta potřeba jednotkových testů vychází právě z té role kolega/spoluautor, nikoli zákazník/uživatel.

A ještě se musím vrátit k tomuto, protože mi přijde, že ses chytil toho zákazníka/uživatele a úplně přehlédl ty požadavky:

vzhledem k požadavkům zákazníka/uživatele jsou unit-testy irelevantní, mimoběžné

Pointa byla v tom, že mít 100% pokrytí jednotkovými testy a mít všechny zelené, neříká nic o tom, že byly splněny požadavky zákazníka. Procházející unit-testy o tom nevypovídají vůbec ale vůbec nic, protože je psal programátor na základě toho, jak pochopil zadání – a na základě téhož pochopení (či nepochopení) zadání psal i ten samotný program – tudíž je dost velká šance², že kód a jednotkové testy budou v souladu. Ale bude v souladu i kód a zadání? O tom unit-testy nevypovídají zhola nic! Tady musí nastoupit nezávislí testeři, kteří ověří funkcionalitu³ na základě zadání (analýzy, specifikace, požadavků zákazníka) a to právě formou integračních/systémových (nikoli jednotkových) testů.

Rozdíl mezi těmito druhy testů není jen v té – jak ty říkáš – granularitě, ale hlavně v tom, kdo a proč je píše.

_{[1] často nejde ani o ověřování funkčnosti, jako spíš o metodu a pomůcku při psaní kódu nebo nástroj k udržení integrity při refaktoringu a dalších změnách – uživatelem (a zároveň autorem) tohoto testu je programátor, nikoli tester nebo nedejbože zákazník (v tvém případě uživatel knihovny)
[2] téměř jistota, protože padající jednotkové testy si programátor většinou vychytá u sebe a nepustí neprocházející kombinací kód+testy ze své pracovní stanice k ostatním
[3] a další požadavky jako třeba výkon, robustnost…}

[xkucf03]

Procházející unit-testy o tom nevypovídají vůbec ale vůbec nic, protože je psal programátor na základě toho, jak pochopil zadání – a na základě téhož pochopení (či nepochopení) zadání psal i ten samotný program – tudíž je dost velká šance2, že kód a jednotkové testy budou v souladu. Ale bude v souladu i kód a zadání? O tom unit-testy nevypovídají zhola nic!

Ještě takový příklad: když zapomeneš implementovat funkcionalitu z požadavku #1234 tak se to na jednotkových testech neprojeví vůbec nijak – všechny budou krásně procházet a budeš mít 100% pokrytí – jednoduše proto, že jednotkové testy píšeš pro jednotky – a dané jednotky (třídy/funkce), které by tu funkcionalitu měly implementovat, vůbec neexistují.

Jestli chceš otestovat soulad s požadavky, tak na to musíš jít ze strany těch požadavků a testy odvozovat z nich – ne ze strany kódu, který programátor napsal (dodatečně psané jednotkové testy) nebo který má v úmyslu napsat (TDD).

[pavlix]

To mi přijde trochu TL;DR na to, že mám na čtení zajímavější věci. Nicméně ani po zběžném prolétnutí podle mě zbytečně dlouhého textu si vůbec nejsem jistý, zda jsi pochopil můj první komentář ani proč jsi měl potřebu na něj reagovat takto.

[xkucf03]

Dokud si nepřečteš to, co jsem doteď napsal, tak nemá cenu abych přidával cokoli dalšího, nerad bych tě zahltil textem

[pavlix]

Zběžně jsem přečetl a potvrdil si, že to pro mě představuje jen hromadu balastu, ze kterého se nic nového nedozvím. Věnuju tomu čas v podstatě jen kvůli tomu, že se to nějakým omylem zařadilo pod můj komentář.

[xkucf03]

Ty jsi reagoval na moji větu:

pokrytí testy¹ a jejich průchod nevypovídá nic o kvalitě z pohledu zákazníka/požadavků

tak jsem se ti snažil vysvětlit, jak jsem to myslel.

_{[1] což bych prosil nevytrhávat z kontextu – jsou jím myšleny jednotkové testy}

[pavlix]

Není mi jasné, co chceš na tak zjevné věci vysvětlovat.

[Josef Kufner]

Já preferuji poněkud jiný styl testů. V podstatě to spočívá ve výpisu na standardní výstup a udělání diffu oproti očekávanému výstupu.

Používám na to PHPT, tedy to, čím se testuje samotné PHP. Vypadá to nějak takto (citováno z http://qa.php.net/write-test.php):

--TEST--
strtr() function - basic test for strtr()
--FILE--
<?php
$trans = array("hello"=>"hi", "hi"=>"hello", "a"=>"A", "world"=>"planet");
var_dump(strtr("# hi all, I said hello world! #", $trans));
?>
--EXPECT--
string(32) "# hello All, I sAid hi planet! #"

Jsou zde tři sekce (umí to však mnohem víc): První je název testu, pak je samotný testovací/testovaný kód a na závěr očekávaný výstup.

Pro použití v C by se to muselo udělat trošku jinak, ale možná by se dal preprocesor ukecat i k něčemu velmi podobnému. Během testů je vytvořeno několik souborů a pokud test projde, tak jsou zas zlikvidovány. Pokdu neprojde, zbydou soubory obsahující diff, aktuální výstup a samostatný zdrojový kód. Testy spouští nástroj, který parsuje soubor s testem, vyrobí dočasné soubory, spustí PHP, zkontroluje výstup a uklidí.

Tento přístup má obrovskou výhodu v tom, že psaní testu lze snadno využít k ladění rozepsaného programu. Tím, že výstupem je text a nikoliv banda assertů, je daleko jednodušší sledovat, co z programu skutečně leze. A jakmile je výsledek uspokojivý, stačí hu uložit jako referenční. Psaní složitých assertů tak zcela odpadá.

[Vojtěch Horký]

Tento přístup má obrovskou výhodu v tom, že psaní testu lze snadno využít k ladění rozepsaného programu. Tím, že výstupem je text a nikoliv banda assertů, je daleko jednodušší sledovat, co z programu skutečně leze. A jakmile je výsledek uspokojivý, stačí hu uložit jako referenční. Psaní složitých assertů tak zcela odpadá.

To je otázka názoru. Mně zase přijde přehlednější, když je hned vedle sebe skutečný výsledek a ten očekávaný. A nemusím v tom (potenciálně dlouhém) --EXPECT-- hledat, který řádek odpovídá kterému. Další věc je, že tohle není platný PHP kód, takže to může rozbít nápovědu v editoru apod. Ale uznávám, že tenhle způsob má i dost výhod.

[Josef Kufner]

Ftip je v tom, že to hledat v --EXPECT-- nemusíš. Dostaneš diff, kde už to je nalezené. Navíc nebývá nijak dlouhý, to už by ten test neměl moc smysl.

Platný PHP kód to může být, pokud aspoň trochu chceš. Když předhodím PHP to, co jsem dal jako ukázku, dostanu:

--TEST--
strtr() function - basic test for strtr()
--FILE--
string(32) "# hello All, I sAid hi planet! #"
--EXPECT--
string(32) "# hello All, I sAid hi planet! #"

[Vojtěch Horký]

Dostaneš diff, kde už to je nalezené.

Já měl na mysli případ, kdy ten test chci rozšířit. Jinak souhlasím.

[pavlix]

Já preferuji poněkud jiný styl testů. V podstatě to spočívá ve výpisu na standardní výstup a udělání diffu oproti očekávanému výstupu.

Hezké. To v jednom případě skutečně používám.

Tento přístup má obrovskou výhodu v tom, že psaní testu lze snadno využít k ladění rozepsaného programu. Tím, že výstupem je text a nikoliv banda assertů, je daleko jednodušší sledovat, co z programu skutečně leze.

Samozřejmě to má i své nevýhody, takže to kombinuju s testováním pomocí assertů, které slouží k prostému odchytání regresí.

Ty asserty mají obrovskou výhodu v tom, že program sletí ve chvíli, kdy je něco vyhodnoceno jako špatné a tím pádem se dá s pomocí debuggeru bleskově zjistit, co se vlastně stalo. Akorát v tomto případě nepoužívám žádný framework, protože mi jednak přijde redundantní (nevidím pro něj potřebu) a jednak by v kódu překážěl ve chvíli, kdy chci kód testu použít zároveň jako ukázku (s asserty jsem v tu chvíli celkem smířený).

[Josef Kufner]

"Asserty" jsem myslel ty, které se používají v těle testu, nikoliv kontroly v těle programu/knihovny. Tedy ty asserty, které jsou v PHPT nahrazeny diffem výstupu.

Asserty v programu samotném jsou užitečné, o tom žádná. I když je to jen zalepování děr v nedostačujícím typovém systému

[pavlix]

"Asserty" jsem myslel ty, které se používají v těle testu

Co jsem odkazoval, je tělo testu. Nicméně to, že test vypadá jako běžný program a lze používat jako ukázka pro uživatele knihovny, považuju za výhodu.