Jak to myslíš? Testy té komponenty má napsat její autor. Pokud ty potřebuješ testovat svůj kód a ta kompnenta ti překáží, tak ji můžeš nahradit nějakou dummy komponentou.
Myslím to tak, jak jsem to v této diskusi několikrát napsal – že testování komponent je jednoduché, ze všech možných testů je to to nejjednodušší testování. Ovšem z toho, že vám procházejí testy komponent, neplyne o funkčnosti programu vůbec nic. Protože program vznikne teprve tehdy, když ty komponenty poskládáte, navzájem je propojíte. Přičemž to propojování zase může být dobře i špatně – to, že propojení fungujících komponent vůbec nezaručuje, že bude fungovat i celek, je klíčová znalost, bez níž nemůžete nic testovat.
Takže postupně. Testy komponenty má napsat autor. Jenže autor napíše testy toho, jak si myslí, že by jeho komponenta měla fungovat. Což je něco jiného, než jak komponenta ve skutečnosti funguje (a tenhle rozdíl se snažíme odhalit pomocí jednotkových testů), a hlavně je to něco jiného, než jak si uživatel myslí, že komponenta funguje (a tohle autorovy testy neodhalí). Konkrétně je to problém rozdílu specifikace a implementace a nejednoznačnosti specifikace (z té nejednoznačnosti mimo jiné plyne, že je lepší, pokud jednotkové testy píše někdo jiný, než autor, protože je jistá šance, že když nejednoznačnou specifikaci jinak pochopí autor implementace a jinak autor testu, implementace pak testem neprojde). Testy jsou svým způsobem také specifikace, jenže uživatel komponenty ji nepoužívá na základě specifikace definované testy, ale na základě specifikace popsané někde v dokumentaci (v lepším případě).
Pokud budu testovat svůj kód, komponenta mi překáží a nahradím ji dummy komponentou (v terminologii testování se používá „mock“ komponenta, česky by se řeklo třeba „falešná“ komponenta), testuju jenom to, zda můj kód funguje s mou představou o fungování té komponenty. Nebo-li neodhalím žádnou chybu plynoucí z toho, že má představa o fungování komponenty je odlišná od toho, jak komponenta doopravdy funguje.
Když to celé dobře dopadne a budu mít kód založený na představě o fungování komponenty, která bude alespoň v rozsahu používání té komponenty odpovídat realitě (což taky nejde 100% otestovat, i když budu mít komponentu dobře testovatelnou), pořád ještě zbývá vazba mezi těmi komponentami. Protože ty komponenty obvykle do sebe nezapadnou tak, jak jsou hotové, ale je potřeba je propojit nějakým kódem. Tenhle kód je závislý na obou komponentách, už jenom proto se bude testovat dost těžko. A často je ten kód velmi závislý na okolním prostředí, což testování ještě dál komplikuje. Aneb když vy mi dáte perfektně otestovanou komponentu, která bude počítat třeba jednoduchý součet, já správně pochopím všechny nuance fungování vaší komponenty, moje mock implementace vaší komponenty se bude chovat úplně stejně, jako vaše komponenta, pořád ještě zdaleka není vyhráno. Protože já tu vaši komponentu budu volat jako webovou službu, nebo pomocí meziprocesové komunikace, nebo třeba jenom ve vícevláknovém prostředí, čímž jste nepočítal – a všechno tohle může tu spolupráci dvou perfektně otestovaných komponent zničit mnoha různými způsoby.
Přičemž shodou okolností tohle propojování komponent tvoří čím dál větší objem napsaného software. Protože těch základních komponent je už spousta a jejich vývoj už se rozhodně nezrychluje. Za to se z těch základních komponent dá skládat čím dál víc různých programů, tedy ten rostoucí objem software mají na svědomí právě ty mezikomponentové vazby. (Proto se taky dnes od spousty programátorů chce, aby uměly ty komponenty spojovat, ale není potřeba, aby je uměly vytvářet. Což někteří programátoři, kteří umějí ty komponenty vytvářet, ale neumějí s nimi dál pracovat, těžce nesou a kompenzují si to tím, že se označují za „opravdové programátory“ a ostatní pak třeba za „lepiče kódu“.) Ty mezikomponentové vazby dnes pořádně testovat neumíme, většinou se snažíme otestovat alespoň něco tak, že to naroubujeme na jednotkové testy, případně použijeme nějaký framework, který ty vazby umožní dělat jednotně a se znovupoužitelným kódem. Což jde ale použít jedině u vlastních komponent v rámci jedné aplikace – když třeba voláte nějakou komponentu jako webovou službu, bez spolupráce protistrany neotestujete skoro nic. Zeptejte se lidí, kteří teď implementují EET do pokladních systémů, jak je to testovatelné – a to EET ještě má alespoň nějaké testovací prostředí.
Snad jsem vám to alespoň trochu objasnil a to, co jste si snad někde přečetl, si teď dokážete lépe srovnat.
Doporučuji ti něco si o tom přečíst a nechytračit tady s buzením o půlnoci.
Až zase někdy narazíte na někoho, kdo tvrdí něco jiného, než vy, a budete mít potřebu ho poučovat, že si má něco přečíst, zvažte variantu, že rozdíl v tvrzeních je způsobený tím, že vy jste si možná něco přečetl, ale nepochopil jste to. Předejdete tak sebeztrapňování, jako se vám to stalo v citovaném komentáři.
Reagoval jsem na větu, že v takovém případě je třeba rezignovat na testování.
Hlavně že jste tam tu větu citoval, že? „Rezignovat na testování“ je něco jiného, než „rezignovat na testování jako ověřování správnosti“.
103 Odpovědí
13550 Zhlédnutí