Začít testovat je jednoduché

test

Kolikrát jste přemýšleli, že začnete testovat? Že „ty testy“ použijete alespoň na nejdůležitější třídy, popřípadě na opakující se chyby? Čas běží a testy pořád nikde! Navíc nadřízení se ptají, zda to nezabere zbytečně čas, který by mohli nafakturovat zákazníkovi. Nebo si snad myslíte, že umíte psát software bez chyb?

V prvním ze série článků se podíváme na dva největší vývojářsko-testovací mýty a vyvrátíme je:

  1. testování zabere příliš mnoho času,
  2. jsem neomylný vývojář a chyby nedělám.

Vývoj bez testů

Už jste někdy napsali v PHP následující kód (nebo velmi podobnou obdobu)?

$obj = new MojeTrida;
$result = $obj->nejakaMetoda($nejakyParametr);
var_dump($result);

Takhle se totiž vyvíjí v PHP nejčastěji. Napíše se třída, zavolá se metoda a pohledem zjistíme, zda to dělá, co to dělat má. Takový kód napíše programátor mnohokrát denně – ostatně na tom není nic špatného. To špatné je, že kód potom smažeme a důvěřivě očekáváme, že se třída nerozbije.

Jenže ona se rozbije! A my, protože jsme si testovací výpis smazali, se o tom dozvíme buďto pozdě (třeba až po nasazení na server), nebo sice brzo, ale kolikrát nám zabere spoustu času zjistit, kde chyba je. Proč? Protože se může projevit v úplně jiné třídě – jen proto, že „side effect“, který má třída způsobit, se za určitých podmínek, nevykoná.

Trvalé testy

Podívejme se na jiný způsob, jak tento výpis použít a přitom si test nechat:

// ... hlavička testu (povíme si později)
$obj = new MojeTrida;
$result = $obj->nejakaMetoda($nejakyParametr);
var_dump($result); // toto až nebudeme potřebovat, tak to zakomentujeme
$this->assertEquals(array(1, 2, 3), $result);
-- ... patička testu (také si povíme později)

Jak vidíte, kód, který jsme napsali, je téměř identický. Samotná třída testu je opakující se šablona, takže její napsání nám nezabere žádný čas navíc (každý slušný editor i IDE umožňuje uložit si šablony kódu). Takto to u testů vždy není, ale mnohdy je vytvoření testu skoro tak jednoduché, jako vytvoření výpisu výsledku.

PHPUnit

Jak vypadá naše šablona v PHPUnitu:

class NazevTridyTest extends PHPUnit_Framework_TestCase
{
    public function testNejakaMetoda()
    {
        // .. zde prijde váš kód
    }
}

Kód spustíme příkazem: phpunit NazevTridyTest.php (test musí být uložen v tomto souboru – je navíc danou konvencí, že názvy souborů testů končí na Test.php) nebo phpunit nazevSlozkySTesty. (Postup instalace PHPUnitu najdete na webu tohoto nástroje.)

Samozřejmě PHPUnit umožňuje mnohem víc, o tom si v příštích dílech napíšeme víc.

Programátoři chybují

Mýtem druhým je, že programátoři nedělají chyby. Toto je skutečně mýtus – a to doslova ohromný! Proč tedy neustále vycházejí minor updaty veškerého softwaru? Tím myslím nejen PHP knihovny, tak i operační systém, databáze, překladače C atd.? Jednoduše proto, že chyb je všude spousta. Podívejte se na libovolný changelog libovolného projektu, najdete tam u minor updatů (a často i u větších verzí) více oprav chyb, než nových vlastností. Zhoubnost tohoto jevu je jasná: méně chyb znamená více vlastností, popřípadě lepší uživatelské rozhraní, dokumentace.

Často slýchávám od programátorů v Javě a dalších staticky typovaných jazycích, že je chrání typové kontroly a že testy nepotřebují. Proč potom pochází většina testovacích knihoven z Javy? Proč největší advokáti testování píší v Javě? A jsou to programátoři s praxí v řádu desítek let, ti testy určitě nepotřebují kvůli nedostatku kompetence.

V zásadě lze ověřit, zda kód funguje, pouze čtyřmi způsoby. Formálním ověřením (pomalé, mnohdy takřka nemožné – žádný zaměstnavatel to nezaplatí, pokud nevyvíjí zrovna ovladače pro umělá srdce apod.), metodou Design by contract (která je sice solidní, nicméně bez podpory přímo v jazyku nepohodlná), automatizovanými testy a nebo neustále klikající stovkou pákistánských testerů (drahé – a to i když najmete ty nejhorší Pákistánce vůbec). Bez testu jednou z těchto metod nelze říct, že kód funguje.

Jeden programátor nikdy v hlavě velký systém do důsledků nepojme – a už vůbec ne, když přijde požadavek na hotfix a na záda mu dýchá nadřízený, jehož asistentka kvůli chybě nemůže pracovat, a vy slyšíte: „Ale vždyť přeci stačí taková maličkost – tady to výsledné HTML jen přepsat regulárním výrazem?!“.

Vývojáři jsou často nuceni do kompromisů. Obvykle na ně přistoupí s podmínkou, že „až bude čas, tak se to přepíše“. Je to taková forma upokojení sama sebe, nicméně to právě zanáší do systému chyby, nejednoznačnosti, nelogické a nekoncepční prvky.

V dalších dílech tohoto článku se dozvíte, jak testovat snadno, nestrávit tím příliš času a přitom jen získávat. Pokročilejší techniky, které se v manuálu nedozvíte, se můžete naučit na školení testování, které pořádá Internet Info spolu s autorem článku Jiřím Kneslem.

Jiří Knesl se zabývá hlavně Scrumem a správným vývojem software (prevence chyb, vyšší produktivita).

Věděli jste, že nám můžete zasílat zprávičky? (Jen pro přihlášené.)

Komentáře: 18

Přehled komentářů

Borek Bernard Růžové brýle
Jiří Knesl Re: Růžové brýle
Borek Bernard Re: Růžové brýle
Jiří Knesl Re: Růžové brýle
Borek Bernard Re: Růžové brýle
Jiří Knesl Re: Růžové brýle
Borek Bernard Re: Růžové brýle
Jiří Knesl Re: Růžové brýle
Honza Marek Zase základy
František Kučera unit testy ⊂ testy
Aleš Roubíček Re: unit testy ⊂ testy
Jiří Knesl Re: unit testy ⊂ testy
Borek Bernard Re: unit testy ⊂ testy
Sniper Re: unit testy ⊂ testy
Karel Alternativy nebo fáze?
Jiří Knesl Re: Alternativy nebo fáze?
Karel Minařík Re: Alternativy nebo fáze?
Jiří Knesl Re: Alternativy nebo fáze?
Zdroj: https://www.zdrojak.cz/?p=3248