Jednotkové testy času (diskuse)

[Tomáš]

Nebylo by lepší používat anglický název unittest? Programátorům to řekne víc.

K tomu času: pokud se to nedá jednoduše oblafnout, tak to bych to řešil tak, že hodnotu zkontroluji jenom jestli tam něco je a nechám to být. Případně v testu se někdy dá načíst stejná hodnota nezávisle, a pak se dá porovnat. Má to výhodu, že člověk zjistí, co mu tam vlastně chodí (ono se to liší podle platformy a člověk pak nevěřícně kouká, co to tam je za blbost).

[zoul]

Když je k dispozici pěkný český překlad, dávám mu přednost. Jednak se většinou líp skloňuje a jednak výsledný text nevypadá jako výstup z automatického překladače :) Kontrolovat jen jestli funkce vůbec něco vrací je blbý, protože alespoň v tom mém případě je podrobná kontrola parsovaného data hlavní pointa testu. Nezávislé načtení hodnoty (tj. nějaké testovací rozhraní nezávislé na zbytku systému, globálním stavu) je samozřejmě ideální, to se shodneme. Přesně to ale v podstatě dělá právě Test::MockTime.

[Marek Bernát]

Sorry, že si musím zasa rýpnuť, ale mne to práve ako z automatického prekladača pripadá. Vždy som unit testy bral tak, že slovo unit tam znamená najmenšia časť kódu, ktorá robí niečo užitočné v danom kontexte. Takže "testovanie častí" je podľa mňa oveľa lepší preklad. Jednotkový test znie skôr ako keby tam išlo o nejakú jednotku v zmysle čísla, alebo o fyzikálne jednotky. Málokto si slovo jednotka predstaví ako časť celku.

A btw, ten tvoj problém som absolútne nepochopil, zbytočne v blogu šetríš slovami. Mohol by si to vysvetliť trochu lepšie, že čo sa snažíš dosiahnuť, a prečo by to v iných jazykoch nefungovalo?

[zoul]

(1) Jde o zavedený překlad, to jsem si nevymyslel. (2) „Unit“ se jako „jednotka“ překládá i v jiných kontextech, takže je to dobré dodržet i tady. (3) Výraz „jednotka“ mi jako označení základních stavebních bloků nepřipadne zlý. „Testování částí“ by klidně mohlo být testování složitejších částí systému, například autentizačního systému a podobně. Ve výrazu „unit“ jde právě o tu nedělitelnost.

V blogu šetřím, protože ho používám především jako poznámkový blok. Na víc nemám čas ani ambice. Pokud se někdo s problémem času v jednotkových testech setkal, bude vědět, o čem mluvím, takže článek přeci jen není pouze pro mě. (Doufám.)

Jeden ze základních problémů jednotkových testů je izolace testovaných komponent od zbytku systému. Pokud se kus kódu nedá rozumně izolovat, nedá se rozumně testovat. Ideální je, když může člověk testovanou komponentu samostatně zapojit v „laboratorním“ prostředí, kde má všechny vstupy pod kontrolou. Test je pak deterministický a jednoduchý. Pokud komponenta pracuje s reálným časem, závisí na nějakém globálním stavu systému, a tahle závislost komplikuje testování.

Jedna možnost, jak tuhle závislost vyřešit, je připsat testovací rozhraní. Nějakou „diagnostickou konzoli“, která umožní nahradit reálný čas laboratorním časem, na kterém se dají dobře odzkoušet všechny hraniční případy. Pokud tomu dobře rozumím, ve statických jazycích se to často řeší pomocí inversion of control. Pokud je jazyk dynamičtější, nabízí se jednodušší řešení, kterému se říká monkey patching – člověk prostě nahradí část testovaného kódu nebo runtimu svým vlastním kódem, který poslouží jako potřebné testovací rozhraní.

V postu jsem chtěl především upozornit na šikovný perlový modul, který umožňuje v testech nafixlovat reálný čas. Pokud někdo pracuje v Perlu a potřebuje testovat nějaký kód, který si hraje s časem, možná mu přijde vhod. Na ukázce zdrojáku je pak vidět, jak jednoduše se dá takový monkey patching provést.

[Marek Bernát]

Ok, to znie vcelku rozumne. Ale ja, ak dovolíš, sa budem držať názvu unit test

Jj, viem presne o čo ide v unit testoch, len som nepochopil ten tvoj problém kvôli tomu, že sám už pracujem prakticky výlučne v dynamických jazykoch a tam je to, ako hovoríš, triviálne, takže ani nemá cenu to rozoberať A ešte jednoduchšie je to, ak človek pracuje vždy s REPLom a len si naťahuje skompilovaný kód (bežná práca s Lispom cez SLIME), a ešte oveľa viac v Squeaku, kde nič ako program ani neexistuje, ale všetok kód stále beží -- to je tá tvoja diagnostická konzola, len dotiahnutá ešte oveľa ďalej.

V statických jazykoch je to holt ťažké a človek si bez nejakých nadbytočných hookov a patternov asi neporadí. Samozrejme, záleží od toho, v ktorých statických jazykoch. Napríklad taký Haskell je čisto funkcionálny, takže pojem stav neexistuje a stačí kontrolovať len vstupy/výstupy každej funkcie -> ideálna situácia pre testera

 

[default]

Já tohle řešil. Při analýze jsem vycházel ze zkušeností se špatně napsanou aplikací. Ta aplikace má totiž rozdělenou business logiku. Jedna část je v Javě a druhá — na jiném stroji — v databázi. Aplikace zahazuje čas; ukládá jen datum. To se jeví jako elegantní obejití problému s vyhledáváním (netřeba porovnávat na rozsahy). Co už ale hoši nedomysleli, je způsob práce této aplikace. Ta totiž největší práci dělá přes noc. A v noci se děje co? No láme se datum.

Takže já ve svých komponentách zavedl pojem business date. Naprogramovat pro to provider je triviální. Na první pohled si člověk řekne, co že to je za hovadinu: obalovat SYSDATE. Ale těch providerů může být několik. Jeden vytáhne datum z aplikáče, druhý z databáze, třetí odněkud odjinud. Navíc to business date je konstantní pro všechny komponenty po celou doby noční dávky.

Ale ta hlavní výhoda spočívá právě v těch tvých jednotkových testech času (mimochodem — až z diskuze jsem pochopil, co ten termín skutečně znamená). Prostě napíšu Mock Provider, kterej to datum tahá z konfiguráku. Klidně si ten Mock objekt můžeš předat pomocí IoC.

Osobně si troufám tvrdit, že když nějaký proces potřebuje ke své činnosti datum, pak to datum má být parametrem. Takže je to spíš takový workaround na špatně navrženou (naimplementovanou) aplikaci.

Ale jinak je to všechno v pořádku. Občas potřebuješ otestovat něco, co prostě není úplně ready. Jako to tady děláme my pořád dokolečka s tou aplikací, kterou jsem popsal v úvodu. A jako že je to zábava udržovat testovací datum na několika strojích, když by stačil konfigurák.