Pokusím se to vysvětlit lépe. Při BlackBox testech pracujeme pouze se očekávanými vstupy a výstupy. Cesta, díky které se ze vstupu stane výstup, je nám skryta. A právě tato cesta může obsahovat i "odbočky", které BlackBox testování nemusí odhalit. Právě v tom je přínos WhiteBox testování založeném na analýze zdrojového kódu.

Už jsme tu někde psal, že techniky testování slouží k tomu, aby pomohly testerovi identifikovat jaké testy a v jakém množství je nutné nad aplikací provést, aby bylo možné říci, že je otestovaná a především funkční. U WhiteBox testování jsou tyto techniky založené na analýze struktury kódu. Jsou zaměřené na vytváření testů pokrývající konkrétní konstrukce ve zdrojovém kódu. Uvedeme si tu ty nejzákladnější techniky.

Testování příkazů

Cílem této techniky je pokrýt testy jednotlivé příkazy v kódu. Snahou je samozřejmě pokrýt testy co největší procento příkazů. V této technice jde o tzv. proveditelný příkaz. Jednoduše řečeno jde o všechny příkazy mimo těch, které určují "směr průchodu" jako jsou třeba podmínky nebo cykly. 

Je doufám jasné, že pro tuto techniku neplatí, že každý jednotlivý příkaz by měl být pokryt samostatným testem. Jde o to, aby testy, které jsou vytvářeny pokrývaly co největší počet příkazů v aplikaci, ideálně 100%. 

Testování rozhodování

Tuto techniku prosím neplést s testování rozhodovací tabulky. Zde jde o něco jiného. Tato technika se zaměřuje na podmínkové větvení v kódu. Je asi zřejmé, že každá podmínka a v kódu vytváří větve, kterými aplikace prochází za splnění daných podmínek. Testování při použití této techniky by měly pokrývat všechny větve, které v aplikaci díky podmínkám vznikají. Cílem je tedy vytvořit testy, které splňují vstupní podmínky do jednotlivých větví podmínek a s nimi testovat korektní průchod tímto větvením. Někdy je tato technika označována také jako "testování větvení". Ovšem tohle označení není úplně přesné. Nebo ještě jinak, někdy se mezi testováním rozhodování a testováním větvení nedělá za každou cenu rovnítko.

Například tento materiál rozlišuje mezi podmínkami, které vedou k větvení a těmi, které ne. Zkrátka ne každá podmínka, která se v kódu vyskytuje, znamená zároveň také rozdělení průběhu skrz kód na rozdílné větve. Někdy slouží podmínky například pouze k nějakému nastavení konkrétní proměnné bez toho, že by to na větvení mělo vliv (a když tak třeba jen nepřímý, kdy je tato proměnná použita v jiné podmínce jak kritérium). Tuto skutečnost je nutné zohlednit při vytváření testů. Pokud by byly zaměřené pouze na větvení, pak je možné, že některé podmínky (a tedy rozhodování) nebudou testy pokryty.

Testování podmínek

Přestože se může zdát, že jde jen o jiné pojmenování testování rozhodování, není to (úplná) pravda. Ono zde jde o lehké překrývání pojmů podmínka, rozhodování a kritérium. Zatímco testování rozhodování se zaměřuje čistě na důsledek aplikace podmínky, testování podmínek se snaží testovat situace, na základě kterých k rozhodování dochází.

Příklad je lepší než stránky popisů. Proto si tu ukážeme, o čem testování podmínek je. V kódu může existovat podmínka v podobné podobě:

If (Kritérium1 and (Kritérium2 nebo Kritérium3))

   příkaz1

Else

   příkaz2

End

Pro otestování rozhodování by nám zde stačily dva testy. Jeden by testoval větev pro výsledek rozhodování "Pravda" a druhý "Nepravda". Pro první z těchto testů by tak byly nastaveny vstupy tak aby splnily vstupní podmínku a pro druhý pochopitelně aby ji nesplnily. 

Testování podmínek se zaměřuje čistě na kritéria rozhodování. Jeho úkole, je otestovat všechny kombinace vstupů, které dávají smysl vzhledem k podmínce. Tedy v tomto případě by se testovaly například tyto kombinace:

1) Kritérium1 = Pravda, Kritérium2 = Pravda, Kritérium3 = Nepravda

2) Kritérium1 = Pravda, Kritérium2 = Nepravda, Kritérium3 = Pravda

3) Kritérium1 = Pravda, Kritérium2 = Pravda, Kritérium3 = Pravda 

4) Kritérium1 = Pravda, Kritérium2 = Nepravda, Kritérium3 = Nepravda 

Atd.

Je zřejmé, že testování podmínek je podrobnější než testování rozhodování. Dá se říci, že nejméně podrobné je testování větvení, podrobnější je testování rozhodování a nejpodrobnější je testování podmínek. To ale záleží na složitosti struktury kódu i složitosti podmínek a jejich kritérií.

Testování cesty

Poslední z hlavních technik, které tu chci uvést, je testování cesty. Tato technika představuje komplexnější pohled na procesy uvnitř aplikace. Zatímco všechny již zmíněné techniky se zaměřovali na malé úseky kódu, testování cesty se snaží pokrývat cesty, kterými aplikace prochází od vstupu po výstup. Každá taková cesta představuje sekvenci příkazů, podmínek a větví v kódu a každá taková sekvence by v rámci testů měla být jedinečná. Jinak řečeno cílem je identifikovat takový sled větvení, který vede od definovaného vstupu k očekávanému výstupu. Může to svádět k představě, že jde vlastně BlackBox testování. Ale není tomu tak. Přístup zde je jiný. Mluvíme zde o vstupech a výstupech tak jak je chápe aplikace, ne o vstupech z pohledu uživatelského. Kombinace vstupů může vyvolat zcel odlišný průchod aplikací a roli může hrát například i pořadí vstupů. K výstupu může vést více než jedna cesta a jednomu vstupu nemusí odpovídat jeden výstup.

Pokud se oprostíme od BlackBoxového uvažování, pak testování cesty skutečně komplexní analýzou aplikace z pohledu jejího kódu. pro každý vstup zkoumáme všechny možné průchody a to z pohledu všech větvení a příkazů, kterými prochází. To znamená velké množství testů. S každým větvením se počet testů exponenciálně zvětšuje. Navíc je nutné vzít v úvahu, že při tomto přístupu je možné, že testy budou obsahovat takovou kombinaci vstupů, ke které reálně nemůže dojít. Tedy cesta, která tyto vstupy dokáže zpracovat, v aplikaci existuje, ale v důsledku například nějakých business pravidel (ošetřených třeba pomocí jiné aplikace) tato kombinace vstupů do aplikace nikdy přijít nemůže. Je zde tedy nebezpečí, že aplikace této techniky bez toho, že by navržené testy prošly nějakou formou revize a prioritizace, může vést k enormnímu nárůstu prováděných testů. 

Technik testování kódu existuje mnohem víc než tu uvádím. Vybral jsem jen ty, které mi přijdou nejtypičtější a nejznámější.