V následujících dvou dílech seriálu o testování v PHP uzavřeme pomyslnou kapitolu o frameworku PHPUnit a podíváme se na poslední dvě části, která nám ještě chybí a těmi jsou: XML konfigurace frameworku a parametry příkazové řádky, jež nám umožňují řídit běh našich testů. Dnes se podíváme na parametry příkazové řádky a na report pokrytí kódu testy.

Parametry příkazové řádky

Spouštění vybraných testů

V předchozích dílech jsme vždy spouštěli všechny testy, což nemusí být vždy to, co chceme. Potřebujeme-li spustit pouze vybraný test, pak použijeme volání:

$ phpunit UnitTest

UnitTest je název třídy, která dědí od PHPUnit_Framework_TestCase a je umístěna v souboru UnitTest.php. Pokud je uložena v souboru s jiným názvem, pak je třeba doplnit ještě třetí parametr s názvem souboru:

$ phpunit UnitTest UnitTestFile.php

–filter pattern

Spuštění pouze těch testů, které odpovídají zadanému regulárnímu výrazu.

–group group1,group2

Spuštění pouze testů, které jsou označeny uvedenými anotacemi @group nebo @author.

–exclude-group group1,group2

Opak předchozího přepínače – spuštění všech testů s výjimkou těch, které jsou označeny uvedenými anotacemi @group nebo @author.

–test-suffix suffix

Změna defaultní přípony názvu souborů, ve kterých jsou testy hledány. Defaultně: Test.php,.phpt

Logování výsledků

–log-junit filename

Uložení výsledků testů ve formátu JUnit XML pro další zpracování. Více info o formátu: http://ant.apache­.org/manual/Tasks/junit.html.

–log-tap filename

Uložení výsledků testů ve formátu Test Anything Protocol (TAP) pro další zpracování. Více info o formátu: http://en.wiki­pedia.org/wiki/Test_Anythin­g_Protocol.

–log-json filename

Uložení výsledků testů ve formátu JSON.

Report pokrytí kódu testy

Jednou z dalších možností, které framework PHPUnit nabízí, je generování reportu pokrytí kódu testy, tzn. code-coverage. V průběhu testování framework sbírá data o tom, které řádky testovaného kódu byly projity a které nikoli a na základě těchto informací je potom schopen vygenerovat souhrnné info. Buď v podobě datového souboru pro pozdější zpracování nebo v podobě HTML reportu – sady vzájemně prolinkovaných HTML stránek s výpisy testovaného kódu doplněné o grafické vyznačení, které řádky byly testy projity a které nikoli.

Pokud se vrátíme k dílu s příkladem, pak code coverage report by mohl vypadat třeba následovně: 

V souhrnu vidíme, že poslední běh testů prošel 88,89 % kódu třídy BankAccount, metoda transfer nebyla testy pokryta vůbec. Patrně jsme ji ještě netestovali. Jakmile začneme metodu pokrývat testy, pak můžeme vidět, které řádky už byly pokryty a které nikoli (testovali jsme případy neplatných vstupů): 

V neposledním případě můžeme vidět seznam testů, které daný úsek kódu pokrývají: 

Code coverage report je celkem užitečný pomocník, ale je třeba jej brát pouze jen jako zdroj informací, ne jako měřítko kvality kódu. Stoprocentní pokrytí kódu testy rozhodně neznačí, že testovaný kód je bezchybný! Hodí se spíše jako nápověda, na které testovací případy jsme zapomněli.

Pro generování code coverage je nutné mít nainstalované rozšíření Xdebug!

–coverage-html directory

Do zvoleného adresáře bude vygenerována HTML verze reportu – sada samostatných, navzájem prolinkovaných HTML stránek.

–coverage-clover filename

Vygeneruje code coverage report ve formátu Clover XML pro další zpracování. Více info o formátu: http://www.atlas­sian.com/software/clover/o­verview.

–coverage-php filename

Vygeneruje výsledek code coverage analýzy a uloží jej v serializované podobě pro další možné zpracování.

–coverage-text=filename

Vygeneruje souhrnné informace o pokrytí kódu testy v textové podobě. Tento souhrn je možné zobrazit v konzoli, použijeme-li jako název souboru: php://stdout Pozor na nestandardní rovnítko!

Dokumentace

–testdox-html filename

–testdox-text filename

Vygeneruje tzv. TestDox dokumentaci buď ve formátu HTML (ul-li seznam) nebo v plain textu. 

Nastavení výstupu

–tap

Výsledky testů jsou vypisovány v TAP formátu: http://en.wikipe­dia.org/wiki/Test_Anythin­g_Protocol.

–testdox

Výsledky testů jsou vypisovány ve formátu TestDox.

–colors

Zapnutí barevného výstupu.

–stderr

Výsledky testů jsou vypisovány do chybového výstupu namísto standardního výstupu.

Řízení běhu

–stop-on-error

Běh testů bude zastaven při první chybě. Chybou není myšleno selhání testu (nesprávný předpoklad), ale runtime chyba Může jít o nezachycenou výjimku, nebo některou z odchytitelných chyb v php (notice, warning, error). PHPUnit interně převádí všechny tyto chyby na výjimky.

–stop-on-failure

Běh testů bude zastaven při prvním selhání některého z testů.

–stop-on-skipped

Běh testů bude zastaven pokud PHPUnit narazí na test označený k přeskočení. Viz druhý díl seriálu.

–stop-on-incomplete

Běh testů bude zastaven pokud PHPUnit narazí na test označený jako neúplný. Viz druhý díl seriálu.

–strict

Spuštění testů v tzv. striktním módu. Ve striktním módu musí mít každý test case alespoň jeden assert, jinak je test označený jako neúplný a běh testů je ukončen. Dále je ověřováno, zda doby trvání jednotlivých test case odpovídají anotacím @small, @medium a @large.

• @small – max. 1 vteřina
• @medium – max. 5 vteřin
• @large – max. 10 vteřin

–repeat x

Opakovat x-krát běh testů.

–verbose, -v

Zapnutí podrobnějšího výpisu, jsou např. vypisovány názvy přeskočených nebo neúplných testů.

–process-isolation

Každý test je spuštěn v samostatném procesu. Výhodou je dokonalejší odstínění testů, nevýhodou vyšší náročnost.

–no-globals-backup

Potlačení zálohování globálních proměnných a jejich obnově po běhu testů. Pro více informací doporučuji kapitolu o anotacích.

–static-backup

Zapnutí zálohování statických atributů a jejich obnově po běhu testů. Pro více informací doporučuji kapitolu o anotacích.

–loader classname

Změna defaultního loaderu na uživatelsky definovaný. Vlastní loader musí implementovat rozhraní PHPUnit_Runner_TestSuiteLoader.

–printer classname

Změna defaultního printeru (třídy zajišťující výpis průběhu testů) na uživatelsky definovaný. Vlastní printer musí dědit od třídy PHPUnit_Util_Printer a implementovat rozhraní PHPUnit_Framework_TestListener.

Nastavení prostředí a připojení XML konfigurace

–bootstrap filename

Bootstrap soubor, který je spuštěn před vlastním během testů. Je možné v něm např. definovat vlastní autoloading testovaných tříd apod.

–configuration filename, -c filename

Nastavení cesty k souboru s XML konfigurací. Pokud není tento přepínač uveden, pak se PHPUnit pokusí načíst soubor s XML konfigurací z aktuálního adresáře. Nejprve je hledán soubor s názvem phpunit.xml a není-li nalezen, je opakován stejný postup pro soubor phpunit.xml.dist

Jsou-li v aktuálním adresáři přítomny oba soubory (phpunit.xml i phpunit.xml.dist), pak je upřednostněn soubor phpunit.xml Díky tomuto postupu je možné mít jiný soubor s konfigurací (phpunit.xml.dist) ve vývojovém prostředí a jiný soubor s konfigurací (phpunit.xml) v testovacím prostředí.

–no-configuration

Ignorování souborů s XML konfigurací v aktuálním adresáři.

–include-path paths

Nastavení dalších adresářů před standardně nastavené v direktivě include_path.

-d key[=value]

Přetížení direktiv ze souboru php.ini

Další přepínače

–list-groups

Výpis všech skupin testů, které jsme vytvořili pomocí anotace @group nebo @author.

–debug

Zapnutí ladících informací o běhu testů.

–help, -h

Výpis nápovědy.

–version

Výpis verze frameworku.

Příště

Příště dokončíme první část seriálu a podíváme se na XML konfiguraci PHPUnit, organizaci testů do tzv. suites a další možnosti.