„Přesvědč mě, proč bych měl používat Nette Tester, v čem je lepší než PHPUnit?“ Tyhle otázky mě vždycky trošku uvádějí do rozpaků, neboť nemám potřebu nikoho přesvědčovat, aby Tester používal. Sám bych se bez něj ale neobešel.

Samotné testování je poněkud zakletá věc. Pět let se na všech konferencích stále dokola mluví o testování a přitom skoro v žádné firmě se kód „netestuje“. Píšu to v uvozovkách, protože ve skutečnosti všichni programátoři dnes a denně testují, co ale nedělají je, že nepíšou testy v PHPUnit, z mnoha důvodů. Pravda je, že sám jsem v oné krátké době, kdy byl Nette Framework testován PHPUnitem, také ztratil chuť testovat. Přičemž testování je pro vývoj frameworku natolik zásadní prvek, jako třeba verzovací systém.

Ale popořadě. Proč všichni programátoři testují, i když „netestují“?

Představte si, že naprogramujete funkci foobar()

function foobar($x, $y) {
	// tady se počítají nějaké věci
	return $val;
}

První věc, kterou každý programátor udělá, je, že vyzkouší, jestli to funguje:

echo foobar(10, 20);

Spustí to, vypíše to 30, což je správně, vypadá to, že to funguje a třeba ještě vyzkouší pár jiných vstupů.

Jinými slovy funkci otestuje. Tedy testuje!

Potom následně udělá to, že testovací skript smaže. A to je právě průšvih! Všechny ty argumenty vývojářů, že na testování nemají čas, v tento moment padají, protože realita je taková, že na testování čas je, dokonce jsou napsané i testy, jenže pak je programátoři smažou. Ironie.

Testem není pouze třída v PHPUnit, testem je i tento jednořádkový skript. Přesněji řečeno, test musí obsahovat ještě informaci, jaká je správná návratová hodnota, takže by vypadal takto:

assert( foobar(10, 20) === 30 );
assert( foobar(-1, 5) === 4 );
...

Až někdy v budoucnu upravím implementaci funkce foobar, nebo do ní sáhne kolega, stačí tento skript spustit, a pokud vyhodí warning, hned vím, že je funkce rozbitá.

A to je vše. Tohle je testování. Tak je to jednoduché. Děláme to všichni, bohužel hodně z vás si ty testy pak maže.

Časem se nám nahromadí obrovská spousta takovýchto testovacích skriptíků a vznikne otázka, jak je spouštět hromadně. Dá se to řešit nějakým shell skriptem, já jsem si na to napsal PHP skript. Jeho podstatnou výhodou je, že umí testy pouštět paralelně (běžně spouštím 40 vláken), což otestování celé sady dramaticky zrychlí. A taky přehledně vypisuje, ve kterém souboru kde přesně došlo k selhání.

Také místo PHP funkce assert jsem si napsal vlastní funkce (třída Assert), které se liší především v tom, že při selhání hezky a čitelně vypíšou, co funkce měla vrátit a co místo toho vrátila, abych rychle věděl, kde je problém.

A ten spouštěč, třída Assert a ještě dalších pár věcí tvoří zmíněný Nette Tester. Čtyři roky spolehlivě testuje Nette Framework.

Když mi někdo nahlásí, že ve funkci foobar je chyba, že pro vstupy 0 a -1 vrací prázdný řetězec místo čísla -1, tak začnu tím, že to nejprve ověřím:

Assert::same( -1, foobar(0, -1) );

Spustím to a skutečně, vypíše se:

Failed: '' should be -1

Tedy jsem napsal failující test. Neudělal jsem to proto, že v příručkách o testování se píše, že test musí nejdřív failovat, nebo proto, že bych se řídil TDD, dělám to proto, že mě nenapadá, co jiného by se dalo dělat, než prostě napsat krátký kód, který bugreport ověří, tedy failující test.

Chyba tam vážně je a je třeba ji opravit. V IDE začnu kód krokovat a hledám místo, kde je zakopaný pes. (O programátorech, kteří píší kód v poznámkovém bloku, ať už se jmenuje TextMate nebo Sublime, namísto plnohodnotného IDE, a nemohou proto kód krokovat, napíšu článek někdy příště.) Ano, kde je chyba bych asi zjistil i bez krokování, zíráním do kódu a umisťováním var_dump, echo nebo console.log, ale trvalo by to mnohem déle. Chci zdůraznit, že krokování a testování nejsou alternativy, ale zcela odlišné činnosti, které je fajn používat dohromady.

Odhalím a opravím chybu, Assert::same je spokojený a do repozitáře komitnu nejen opravu funkce foobar, ale také onen soubor s testem. Díky tomu se tahle chyba už nikdy v budoucnu nevyskytne. A věřte mi, že chyby mají tendenci se opakovat, dokonce pro tento jev existuje název: regrese.

Tohle povídání vám asi muselo připadat strašně samozřejmé. A to je dobře, ono je samozřejmé a já chci bourat předsudky a obavy z testování. Ale stále jsem neodpověděl na úvodní otázku: proč nepoužívám PHPUnit? Protože s ním takto přímočaře pracovat neumím.

Abych mohl otestovat foobar, musel bych napsat celou třídu, která dědí od jiné třídy, jejíž jméno si nejsem schopen zapamatovat. No budiž, použiji šablonu. PHPUnit neumí testy spouštět paralelně, takže otestování celé sady trvá násobně déle. V případě Nette Frameworku jde o 35 sekund versus 2 minuty, což už saje. Ale především, testy psané v PHPUnitu lze spouštět jen v PHPUnitu, nejde o samostatně spustitelné skripty. Takže není způsob, jak napsat failující test a potom ho úplně snadno krokovat a hledat výše uvedeným způsobem chybu.

Nejjednodušší řešení proto bylo napsat si vlastní triviální testovací udělátko. Za ty čtyři roky velmi pozvolna vyspěl v plnohodnotný nástroj, už ho nevyvíjím sám a díky klukům z Oracle má dnes integrovanou podporu v NetBeans 8.0. Jelikož generuje výstup ve formátu TAP, neměl by být problém ani s integrací do jiných nástrojů.

Nebudu vás přesvědčovat, abyste používali Nette Tester, ale rád bych vás přesvědčil, abyste si testy, které píšete, nemazali 🙂