Na navigaci | Klávesové zkratky

Velestručné testování presenterů v Nette

Téma testování presenterů by vydalo na celý seriál, ale ušetříme si čas a místo toho popíšu, jak v několika krocích začít. Aktualizováno pro Nette 2.3.

Jako testovací framework budu používat Nette Tester. Pochopitelně by šel použít třeba i PHPUnit.

A jako vzorovou aplikaci můžeme vzít třeba Nette Sandbox, protože jej najdete v každé distribuci Nette, nebo si ho můžete stáhnout, včetně frameworku, pomocí Composeru:

composer create-project nette/sandbox myApplication

V něm už máme připravený testovací bootstrap, který vytváří DI kontejner (a vlastně se moc neliší od klasického app/bootstrap.php).

Vyrobíme si tedy instanci presenteru. Buď ručně operátorem new a předáme všechny závislosti, nebo jednodušeji za využití PresenterFactory:

// z DI kontejneru, který vytvořil bootstrap.php, získáme instanci PresenterFactory
$presenterFactory = $container->getByType('Nette\Application\IPresenterFactory');

// a vyrobíme presenter Sign
$presenter = $presenterFactory->createPresenter('Sign');

A bude vhodné vypnout autoCanonicalize, aby presenter nepřesměrovával na kanonické URL:

$presenter->autoCanonicalize = false;

A rovnou můžeme začít testovat, třeba akci Sign:in:

// zobrazení stránky Sign:in metodou GET
$request = new Nette\Application\Request('Sign', 'GET', array('action' => 'in'));
$response = $presenter->run($request);

Presenter je stavěn na jedno voláním run(), pro další requesty vytvoříme vždy nový presenter.

Ověříme, zda odpověď je skutečně šablona:

Assert::type('Nette\Application\Responses\TextResponse', $response);
Assert::type('Nette\Bridges\ApplicationLatte\Template', $response->getSource());

Necháme šablonu vygenerovat HTML kód:

$html = (string) $response->getSource();

A nyní třeba zkontrolujeme, zda se na stránce nacházejí formulářová políčka pro jméno a heslo. Syntax je stejná jako u CSS selektorů.

$dom = Tester\DomQuery::fromHtml($html);

Assert::true( $dom->has('input[name="username"]') );
Assert::true( $dom->has('input[name="password"]') );

Toliko úvodem.

Komentáře

  1. Matto #1

    avatar

    Nerozumiem, aký účeľ má testovanie prezenterov.
    Možno je to len nevhodne zvolený príklad, ale nie je jednoduhšie si to otvoriť v prehliadači a pozrieť sa či tam tie dva inputy naozaj sú?

    před 11 lety | reagoval [2] TheTom [4] David Grudl
  2. TheTom #2

    #1 Matto, Dokud je presenter jeden, tak samozřejmě ano. Až bude 10 presenterů po 10 akcích, bude lepší spustit hromadný test než otevřít 100 stránek, zvlášť když každá změna kódu někde na pozadí může ovlivnit kdejaký zapomenutý presenter…

    před 11 lety
  3. Pavel Železný #3

    avatar

    Jen mi na tom nevyhovuje, že nejsou namockovany všechny závislosti. Jinak díky za tip.

    před 11 lety | reagoval [4] David Grudl
  4. David Grudl #4

    avatar

    #1 Matto, Ať už jde o testování presenterů nebo čehokoliv jiného, cílem je proces automatizovat. Aby místo zdlouhavého procházení v prohlížeči stačilo spustit jeden skript. A ten pak spouštět po každé úpravě.

    #3 Pavle Železný, V takovém případě si presenter vytvoříš operátorem new a mocky závislostí mu předáš. Jen to pak není velestručné ;)

    před 11 lety
  5. Matto #5

    avatar

    „Aby místo zdlouhavého procházení v prohlížeči stačilo spustit jeden skript“
    ale ten skript treba pred tým napísať a ak berieme do úvahy, že každý prezenter je iný tak nám to potom zaberie viac času, nie?

    před 11 lety | reagoval [6] David Grudl [7] v6ak
  6. David Grudl #6

    avatar

    #5 Matto, jsem maximálně dalek toho někoho přesvědčovat, že má testovat ? Každý svého štěstí…

    před 11 lety
  7. v6ak #7

    #5 Matto, Pokud počítáme jedno spuštění, tak nejspíš skutečně ano. Pokud ale jednou napíšu test a sstokrát ho spustím, je to někde jinde.

    před 11 lety
  8. sotech #8

    avatar

    Díky za článek. Otestuju … ?

    před 11 lety
  9. BigCharlie #9

    avatar

    Když chci vytvořit presenter ručně (tj. pomocí new), kde aktuálně zjistím závislosti presenteru? Podle API je závislý na DI containeru Nette.

    Takže musím namockovat container + služby, které potřebuje presenter (ty musím najít v kódu presenteru) a ty vložit do containeru?

    před 11 lety
  10. Ondřej Profant #10

    avatar

    Měl bych nějaké otázky:

    1. Jak vypadá obecná syntax pro

      $request = new Nette\Application\Request(‚Sign‘, ‚GET‘, array(‚action‘ ⇒ ‚in‘));

    např. handly. Rád bych simuloval provedení handle metody.

    1. Při tomto testování se normálně využívají věci cachované v temp, že? (Jednou jsem se setkal s chybou, která to naznačovala a nevidím důvod proč by to tak nemělo být.) Nebylo by dobré nějak nuceně temp přegenerovat?
    2. Je někde oficiální API? Našel jsem: https://web.archive.org/…ette/tester/ nicméně nějaký oficiální odkaz. který bude snadno dohledatelný by se hodil.
    před 11 lety
  11. Petr Kobelka #11

    avatar

    Pěkný článek, díky!

    před 11 lety
  12. php curl https #12

    avatar

    skvělý tutorial, díky

    před 11 lety
  13. Josef Sábl #13

    avatar

    Hází mi to divnou chybovou hlášku:

    E_USER_WARNING: Tester\DomQuery::fromHtml: ID notifications already defined on line 100.

    před 9 lety | reagoval [14] Josef Sábl
  14. Josef Sábl #14

    avatar

    #13 Josefe Sáble, Hmm, nevalidní HTML. Ta hláška vypadala jako něco z PHP, ale je to očividně z XML parseru. Blbý dotaz :)

    před 9 lety
  15. sitnarf #15

    avatar

    A není už rovnou lepší použít Selenium, kde nemusím řešit předávání závislostí a rovnou ten daný form otestuji, i třeba s tím, že mi to neznemožní odeslat JS či CSS a rovnou otestuji např. JS validaci, či jiné JS komponenty.

    před 7 lety

Tento článek byl uzavřen. Už není možné k němu přidávat komentáře.


phpFashion © 2004, 2024 David Grudl | o blogu

Ukázky zdrojových kódů smíte používat s uvedením autora a URL tohoto webu bez dalších omezení.