Myšlenky dne otce Fura

Řada z vás možná už na výraz Mock testing narazila, nÄ›kteří ne. Pro ty z vás, kteří Mock přístup v testování nepoužili je tento Älánek. Pro ostatní může být zajímavá ukázka této techniky na knihovnÄ› EasyMock.

Jedná se vlastnÄ› o techniku psaní urÄitého druhu automatických testů. V podstatÄ› se jedná o nahrazení reálného objektu testovací fasádou, která neprovádí žádnou funkcionalitu nahrazovaného objektu - jen se jako tento objekt tváří. Místo původní logiky objektu je vloženo chování, které ve svém testu potÅ™ebujete.

Nejlepší bude teorii provázat s praxí. Pokud píšete automatické testy, jistÄ› jste narazili na situaci, kdy k napsání jednoduchého testu musíte velmi složitÄ› a pracnÄ› pÅ™ipravovat okolní podmínky. NapÅ™. testujete metodu v business objektu, který se dotazuje internÄ› DAO objektů na data v databázi. To ale znamená, že pÅ™ed tím, než zaÄnete testovat logiku tohoto business objektu, musíte pÅ™ipravit správná data v databázi. Musíte také zajistit, že se tam omylem nedostanou další data, která by test zhatila (napÅ™. v SELECT dotazu vrátila více řádků) a tudíž obvykle zase musíte po sobÄ› uklízet. OÅ¡etÅ™ení okolních podmínek spuÅ¡tÄ›ní testu vás nakonec může stát nÄ›kolkrát více Äasu, než potÅ™ebujete k napsaní vlastní testovací logiky.
Existují různé techniky, jak toto zajistit - setkal jsem se napÅ™. s použitím HSQL databáze, která byla celá v pamÄ›ti a po každém testu se kompletnÄ› dropla a pÅ™ed novým opÄ›t vytvoÅ™ila a dosadila se přísluÅ¡ná testovací data (tím, že se vÅ¡e odehrávalo pouze v pamÄ›ti byly testy velmi rychlé). OvÅ¡em lehÄí je dle mého názoru právÄ› použít techniku mock objektů.

PÅ™i použití této techniky se soustÅ™edíte na testování pouze logiky business objektu a pÅ™edpokládáte že okolní objekty fungují správnÄ› tak jak mají. Potom v naÅ¡em příkladÄ› za DAO objekty dosadíte pouze “prázdné” ulity, které mají stejné rozhraní, ale místo vlastní logiky obsahují logiku takovou, kterou potÅ™ebujete pro vlastní test. Tzn. ve chvíli, kdy se business objekt zeptá DAO na konkrétní data, neprobÄ›hne dotaz do databáze, ale vy mu rovnou vrátíte data, která v daném testu potÅ™ebujete.

To je celý princip mock objektů. Nic víc, nic míň. Pokud se chcete dozvÄ›dÄ›t nÄ›co víc, pokraÄujte ve Ätení.

Pokud chcete použít tuto techniku při testování, potřebujete vyřešit dva problémy:

Ve vlastním testu potom jednoduše vytvoříte testovaný objekt, nastavíte mu místo původní reálné implementace testovací náhražku a zajistíte, aby ta vracela data, která ve svém testu požadujete.

Můžete se vydat cestou tzv. stub objektů - což znamená že vytvoříte fyzicky třídy, které obsahují logiku, kterou od nich požadujete v testech. Je to asi jednodušší cesta pro někoho, kdo s tímto způsobem testů ještě nepřišel do styku, ale cesta dosti pracná.

Dalším vývojovým stupněm jsou tzv. mock objekty. Jejich použití je možná obtížnější, zato přinášejí jednu zásadní výhodu. Dynamické mock objekty jsou vytvářeny přímo testem a existují pouze virtuálně. Tzn. není třeba fyzicky implementovat vlastní mock třídu a navíc vám zdarma poskytnou řadu funkcionality, kterou byste do svých stub objektů pracně implementovali. Příklad použití mock objektů si ukážeme na použití knihovny EasyMock.

Dejme tomu, že máme tento business objekt, který chceme testovat.

Ten používá ke své Äinnosti dvÄ› rozhraní - IMessageSender a ILogger. Vlastní logika business objektu je velmi prostá, pokud dojde Äíslo menší jak 10, poÅ¡le email příjemci jedna. Pokud je Äíslo vÄ›tší, poÅ¡le mail příjemci dva. Pokud se nepodaří odeslat email, tuto chybu zaloguje. Uvedená dvÄ› rozhraní jsou zobrazena níže.

Výše uvedenou logiku bychom normálnÄ› obtížnÄ› testovali, ale s použitím mock objektů to bude triviálnÄ› jednoduché. Kompletní zdrojové kódy jako Maven 2 projekt naleznete na konci Älánku. V nÄ›m je implementace testů jak pomocí Mock, tak i Stub objektů. Nuže, jak vypadá testování s knihovnou EasyMock?

Test první:

V prvním testu chceme otestovat, že pokud je vstupní hodnota 1 odešle se email prvnímu příjemci a zároveň se nezaloguje žádná chyba (odeslání se podaří).

Ve výše uvedeném kódu je několik zajímavých míst.

#1 - zde se vytváří virtuální mock objekt implementující specifikované rozhraní; fakticky zde v tuto chvíli knihovna EasyMock vytvoří novou třídu implementující vaše rozhraní a instanciuje objekt této virtuální třídy;

#2 - zde zavoláme metodu naÅ¡eho rozhraní stejnÄ›, jako bychom to udÄ›lali s reálným objektem; v tomto případÄ›, vÅ¡ak pouze instruujeme mock objekt, že má oÄekávat (po odstartování skuteÄného testu - viz. bod #3) volání metody send s uvedenými parametry

#3 - zde řekneme knihovně EasyMock: až do tohoto bodu jsme programovali tvé chování pro daný test; od této chvíle se chovej dle našich instrukcí (viz. bod #2)

#4 - nastavíme mock objekty do testovaného objektu - tzn. místo původních reálných implementací mu podstrÄíme kukaÄÄí vejce v podobÄ› naÅ¡ich mock objektů

#5 - zavoláme testovanou metodu business objektu - ta proběhne standardním způsobem a business objekt při svém chodu zavolá metodu rozhraní IMessageSender na našem mock objektu - volání proběhne bez problémů, tudíž si business objekt myslí, že vše proběhlo v pořádku (náš mock objekt se tvářil jako reálný objekt)

#6 - verifikace mock objektů - toto je hlavní pasáž mock testování; zde EasyMock prověří, zda celá akce probÄ›hla tak, jak jste ho pÅ™ed replay fází nauÄili; tzn. ověří, že mezi replay a verify doÅ¡lo k jednomu volání metody send na messageMock objektu a že vstupní parametry odpovídaly (equals) vámi definovaným hodnotám z bodu #2; pokud by k volání nedoÅ¡lo, nebo doÅ¡lo vícekrát, Äi nÄ›která z hodnot se liÅ¡ila od vámi specifikovaných, dojde zde k vyjímce a celý test selže; taktéž si povÅ¡imnÄ›te že souÄástí verify je i loggerMock objekt, u kterého jsme neprovádÄ›li žádnou “instruktáž” - v takovém případÄ› ve fázi verify ověří EasyMock knihovna, že nebyla zavolána žádná metoda tohoto rozhraní (což je dobÅ™e, protože v takovém případÄ› by se business objekt zachoval Å¡patnÄ›)

Test druhý:

V druhém testu chceme simulovat chybu odeslání zprávy. Objekt implementující IMessageSender rozhraní by v metodě send měl vyvolat chybu SendException. Business objekt by na to měl reagovat zalogováním chyby rozhraním ILogger.

#1 - vytvoříme business objekt

#2 - opět vytvoříme virtuální mock objekty

#3 - nyní instruujeme EasyMock, že má oÄekávat volání metody logError na objektu loggerMock - pÅ™iÄemž první parametr musí být ne null objekt (String) a druhým parametrem má být objekt pÅ™etypovatelný na třídu SendException (v této Äásti vidíte, že argumenty nemusíte uvádÄ›t exaktnÄ› pÅ™esnÄ› - EasyMock poskytuje abstraktnÄ›jší výrazové prostÅ™edky)

#4 - zde instruujeme EasyMock, že má oÄekávat volání metody send na objektu messageMock s konkrétními vstupními hodnotami (obdobnÄ› jako v testu 1)

#5 - zde je další novinka, zde říkáme EasyMocku aby v posledním volání (viz. bod #4) vyhodil jako výsledek volání exception SendException (obdobně bychom mohli EasyMocku říct, aby poslední volání vrátilo konkrétní návratovou hodnotu záměnou andThrow voláním metody andReturn)

#6 - nyní řekneme knihovně EasyMock: až do tohoto bodu jsme programovali tvé chování pro daný test; od této chvíle se chovej dle našich instrukcí
#7 - nastavíme mock objekty do testovaného objektu - tzn. místo původních reálných implementací mu podstrÄíme kukaÄÄí vejce v podobÄ› naÅ¡ich mock objektů

#8 - zavoláme testovanou metodu business objektu - ta probÄ›hne standardním způsobem a business objekt pÅ™i svém chodu zavolá metodu rozhraní IMessageSender na naÅ¡em mock objektu - pÅ™i volání metody send náš mock vyhodí SendException a náš business objekt by se mÄ›l patÅ™iÄnÄ› zareagovat zalogováním chyby

#9 - verifikace mock objektů - EasyMock ověří, zda na messageMock objektu byla zavolána právě jednou metoda send a parametry volání odpovídaly (equals) předpisu z kroku #4; dále ověří, že na objektu loggerMock byla právě jednou zavolána metoda logError s prvním ne nullovým parametrem a druhým parametrem přetypovatelným na SendException

Výše uvedené příklady prezentují pouze základní a jednoduché možnosti knihovny EasyMock. V druhé verzi má již pomÄ›rnÄ› rozsáhlé možnosti “imitace” a ověřování požadovaného chování. Například umožňuje parametry porovnávat ne jen na ekvalitu, ale má Å™adu výrazových prostÅ™edků z nichž jsme uvedli pouze dva (napÅ™. je / není null, test na regulární výraz, aritmetické operátory >,<,= nebo spojování podmínek pÅ™es logické operátory and, or). PoÄet volání metod lze definovat pÅ™esnÄ› (napÅ™. právÄ› jedno jako v naÅ¡ich testech) nebo v urÄitém limitu - alespoň jednou, od - do, libovolnÄ›. Umožňuje ověřovat poÅ™adí volání konkrétních metod a naopak. Dokáže vytvoÅ™it mock objekty v různých režimech - strict mock (oÄekává volání jen vámi pÅ™edepsaných metod - jinak generuje UnexpectedCallException), nice mock (umožňuje libovolné volání metod na tomto objektu - u neinstruovaných metod vrací "výchozí" hodnoty - null, 0 nebo false).

V druhé verzi je také novinkou Class Extension knihovna, která vám umožňuje generovat mock objekty nikoliv pouze na základě rozhraní, ale i na základě normálních tříd (tzn. není potřeba mít definovaný interface). Tento způsob vám také umožní nechat některé implementace metod mock objektů nepřekryté knihovnou EasyMock - tzn. budou obsahovat původní logiku reálné třídy.

Testy jsou pomÄ›rnÄ› velmi pÅ™ehledné, jednoduÅ¡e se píšou a uÅ¡etří vám plno práce s nastavováním prostÅ™edí pro test. Navíc vám umožní testovat funkcionalitu, která je jen velmi obtížnÄ› testovatelná (napÅ™. že váš skript odeÅ¡le v urÄitou chvíli email).

Je potÅ™eba si uvÄ›domit, že objekty, které nahrazujete se vlastnÄ› netestují. Použití mock objektů vám umožňuje vytváření izolovaných unit testů - ty jsou sice jednodušší a pÅ™ehlednÄ›jší, ale nemají takovou cenu pro vlastní testování jako testy integraÄní. IntegraÄní testy vám pomohou objevit chyby na úrovni rozhraní různých komponent - tzn. ne pouze, komponenta A se chová tak jak má, ale že komponenta B používá komponentu A jak má. Ve výsledku totiž uživatel aplikace nepracuje pouze s komponentami jednotlivÄ›, ale s celým systémem komponent a chyba komunikace mezi komponentami je pro nÄ›j úplnÄ› stejná jako chyba jedné konkrétní komponenty. ProstÄ› to nefunguje.

Zdrojové kódy příkladu ke stažení jako projekt Maven 2

Mock Objects - úvod do techniky mockování
EasyMock - knihovna pro podporu dynamických mock objektů (viz. příklady v Älánku)
jMock - alternativa k EasyMock, abyste si mohli vybrat

Podělte se s ostatními:

OhodnoÅ¥te Älánek:

(3 hlasů, průměrně: 5 z 5)

 Loading ...

ÄŒlánek byl odeslán 19.01.2007 v 7:22 a je zaÅ™azen do kategorie Java, Testování. Reakce na tento Älánek můžete sledovat skrze RSS 2.0 feed. Můžete vložit reakci, nebo vložit odkaz na vaÅ¡e stránky.