Programmer's Reference Guide

Einführung

Zend_Test
Referenzhandbuch für Programmierer

Zend_Test_PHPUnit

Zend_Test_PHPUnit bietet einen TestCase, für MVC Anwendungen die Ausnahmen enthalten, für das Testen einer Vielzahl an Möglichkeiten. Der warscheinlich einfachste Weg um zu verstehen was das ist, ist das ansehen des folgenden Beispiels.

Beispiel #1 Beispiel eines TestCases für ein Anwendungs Login

Das folgende ist ein einfacher TestCase für einen UserController um verschiedene Dinge zu prüfen:

Die Login Form sollte nicht-authenthifizierten Benutzern angezeigt werden.
Wenn sich ein Benutzer einloggt, sollte er zu seiner Profilseite umgeleitet werden, und diese Profilseite sollte relevante Informationen enthalten.

Dieses spezielle Beispiel nimmt ein paar Dinge an. Erstens schieben wird das meiste unseres Bootstrappings in ein Plugin. Das vereinfacht das Setup des TestCases da es uns erlaubt unsere Umgebung geziehlt zu spezifizieren, und es uns ausserdem erlaubt die Anwendung in einer einzigen Zeile zu starten. Unser spezielles Beispiel nimmt auch an das das Setup automatisch lädt sodas wir uns nicht um das laden der betreffenden Klassen kümmern müssen (wie die richtigen Kontroller, Plugins, usw).

class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
    public function setUp()
    {
        $this->bootstrap = array($this, 'appBootstrap');
        parent::setUp();
    }

    public function appBootstrap()
    {
        $this->frontController
             ->registerPlugin(new Bugapp_Plugin_Initialize('development'));
    }

    public function testCallWithoutActionShouldPullFromIndexAction()
    {
        $this->dispatch('/user');
        $this->assertController('user');
        $this->assertAction('index');
    }

    public function testIndexActionShouldContainLoginForm()
    {
        $this->dispatch('/user');
        $this->assertAction('index');
        $this->assertQueryCount('form#loginForm', 1);
    }

    public function testValidLoginShouldGoToProfilePage()
    {
        $this->request->setMethod('POST')
              ->setPost(array(
                  'username' => 'foobar',
                  'password' => 'foobar'
              ));
        $this->dispatch('/user/login');
        $this->assertRedirectTo('/user/view');

        $this->resetRequest()
             ->resetResponse();
        $this->request->setMethod('GET')
             ->setPost(array());
        $this->dispatch('/user/view');
        $this->assertRoute('default');
        $this->assertModule('default');
        $this->assertController('user');
        $this->assertAction('view');
        $this->assertNotRedirect();
        $this->assertQuery('dl');
        $this->assertQueryContentContains('h2', 'User: foobar');
    }
}

Dieses Beispiel können auch einfacher geschrieben werden -- nicht alle der gezeigten Ausnahmen sind notwendig. Hoffentlich zeigt es wie einfach es ist die eigene Anwendung zu testen. This example could be written somewhat simpler -- not all the assertions shown are necessary, and are provided for illustration purposes only. Hopefully, it shows how simple it can be to test your applications.

Bootstrapping der eigenen TestCases

Wie im Login Beispiel gezeigt sollten alle MVC Testcases Zend_Test_PHPUnit_ControllerTestCase erweitern. Diese Klasse ihrerseits erweitert PHPUnit_Framework_TestCase, und gibt einem alle Strukturen und Ausnahmen die man von PHPUnit erwartet -- sowie einiges an Scaffolding und Ausnahme spezifisches der Zend Framework MVC Implementation.

Um die eigene MVC Anwendung zu testen muß diese ein Bootstrap ausführen. Es gibt verschiedene Wege um das zu tun, wobei alle von Ihnen sich der öffentlichen $bootstrap Eigenschaft bedienen.

Zuerst kann diese Eigenschaft so gesetzt werden das Sie auf eine Datei zeigt. Wenn das getan wurde sollte diese Datei nicht den Front Kontroller ausführen, aber stattdessen den Front Kontroller konfigurieren und alles was die Anwendung an speziellen Dingen benötigt.

class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
    public $bootstrap = '/path/to/bootstrap/file.php'

    // ...
}

Zweitens kann ein PHP Callback angegeben werden der nach dem Bootstrap der Anwendung ausgeführt wird. Diese Methode kann im Login Beispiel gesehen werden. Wenn das Callback eine Funktion oder statische Methode ist, könnte Sie auch in der Klasse gesetzt werden:

class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
    public $bootstrap = array('App', 'bootstrap');

    // ...
}

In Fällen in denen eine Objekt Instanz notwendig ist, empfehlen wir die Durchführung in der eigenen setUp() Methode:

class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
    public function setUp()
    {
        // Verwende die 'start' Methode einer Bootstrap Objekt Instanz:
        $bootstrap = new Bootstrap('test');
        $this->bootstrap = array($bootstrap, 'start');
        parent::setUp();
    }
}

Beachte das parent::setUp() aufgerufen wird; das ist notwendig, da die setUp() Methode von Zend_Test_PHPUnit_Controller_TestCase die Erinnerung des Bootstrap Prozesses durchführen wird (was den Aufruf des Callbacks inkludiert).

Wärend der normalen Anwendung wird die setUp() Methode das Bootstrap der Anwendung ausführen. Dieser Prozess wird zuerst das Löschen der Umgebung enthalten um einen reinen Anfragestatus zu erhalten, das Resetieren jedes Plugins, Helfers und Antwort Objektes. Sobald das getan wurde, wird sie anschließend die Datei laden(include) die in $bootstrap spezifiziert wurde, oder den spezifizierten Callback aufrufen.

Das Bootstrappen sollte so nahe wie möglich daran sein wie die Anwendung das Bootstrap durchführt. Trotzdem gibt es einige Fallstricke:

Wir bieten keine alternative Implementierung der Anfrage und Antwort Objekte; diese werden nicht verwendet. Zend_Test_PHPUnit_Controller_TestCase verwendet eigene Anfrage und Antwort Objekte, Zend_Controller_Request_HttpTestCase und Zend_Controller_Response_HttpTestCase. Diese Objekte bieten Methoden für das Konfigurieren der Anfrageumgebung auf gezieltem Wege an, und dem Holen von Antwort Artefakten auf speziellem Weg.
Man sollte nicht erwarten Server spezielles zu testen. In anderen Worten, die Tests garantieren nicht das der Code in einer speziellen Serverkonfiguration läuft, aber das die Anwendung wie erwartet funktionieren sollte, und der Router eine gegebene Anfrage routen kann. Um das Abzuschließen sollten keine Server-speziellen Header im Anfrage Objekt gesetzt werden.

Sobald die Anwendung das Bootstrapping ausgeführt hat, kann damit begonnen werden eigene Tests zu erstellen.

Testen eigener Kontroller und MVC Anwendungen

Sobald man sein Bootstrap hat, kann man mit dem Testen beginnen. Testen funktioniert grundsätzlich wie man es in einer PHPUnit Test Suite erwarten würde, mit ein paar kleinen Unterschieden.

Zuerst muß man eine URL die getestet werden soll ausführen, indem die dispatch() Methode des TestCases ausgeführt wird:

class IndexControllerTest extends Zend_Test_PHPUnit_Controller_TestCase
{
    // ...

    public function testHomePage()
    {
        $this->dispatch('/');
        // ...
    }
}

Es gibt trotzdem Zeiten, , in denen man zusätzliche Informationen angeben muß -- GET und POST Variablen, COOKIE Informationen, usw. Man kann die Anfrage mit diesen Informationen ausstatten:

class FooControllerTest extends Zend_Test_PHPUnit_Controller_TestCase
{
    // ...

    public function testBarActionShouldReceiveAllParameters()
    {
        // Setzt GET Variablen:
        $this->request->setQuery(array(
            'foo' => 'bar',
            'bar' => 'baz',
        ));

        // Setzt POST Variablen:
        $this->request->setPost(array(
            'baz'  => 'bat',
            'lame' => 'bogus',
        ));

        // Setzt einen Cookie Wert:
        $this->request->setCookie('user', 'matthew');
        // or many:
        $this->request->setCookies(array(
            'timestamp' => time(),
            'host'      => 'foobar',
        ));

        // Setzt sogar Header:
        $this->request->setHeader('X-Requested-With', 'XmlHttpRequest');

        // Setzt die Anfrage Methode:
        $this->request->setMethod('POST');

        // Ausführung:
        $this->dispatch('/foo/bar');

        // ...
    }
}

Jetzt wurde die Anfrage durchgeführt, es ist also Zeit Ausnahmen zu prüfen.

Ausnahmen

Ausnahmen sind der Herz vom Unit Testen; Sie können verwendet werden um zu prüfen das die Ergebnisse das sind was man erwartet. Zu diesem Zweck bietet Zend_Test_PHPUnit_ControllerTestCase eine Anzahl an Ausnahmen um das Testen eigene MVC Anwendungen und Kontroller einfacher zu machen.

CSS Selektor Ausnahmen

CSS Selektoren sind ein einfacher Weg um zu Prüfen das bestimmte Teile im Inhalt der Antwort enthalten sind. Mit Ihnen ist es auch trivial sicherzustellen das Elemente die für Javascript UIs und/oder AJAX Integrationen notwendig sind, vorhanden sind; die meisten JS Toolkits bieten einige Mechanismen an für das Abholen von DOM Elementen die auf CSS Selektoren basieren, so das der Syntax der gleiche wäre.

Diese Funktionalität wird über Zend_Dom_Query angeboten, und in ein Set von 'Query' Ausnahmen integriert. Jede dieser Ausnahmen nimmt als erstes Argument einen CSS Selektor, mit optional hinzugefügten Argumenten und/oder einer Fehlermeldung, basierend auf dem Ausnahmetyp. Die Regeln für das schreiben der CSS Selektoren kann im Kapitel Theorie der Anwendung von Zend_Dom_Query gefunden werden. Abfrageausnahmen enthalten:

assertQuery($path, $message = ''): Nimmt an das ein oder mehrere DOM Elemente, die dem gegebenen CSS Selektor entsprechen, vorhanden sind. Wenn eine $message vorhanden ist, wird diese jeder fehlgeschlagenen Ausnahmemeldung vorangestellt.
assertQueryContentContains($path, $match, $message = ''): Nimmt an das ein oder mehrere DOM Elemente, die dem angegebenen CSS Selektor entsprechen, vorhanden sind, und das zumindest einer dem Inhalt, der in $match angegeben wurde, entspricht. Wenn eine $message vorhanden ist, wird diese jeder fehlgeschlagenen Ausnahmemeldung vorangestellt.
assertQueryContentRegex($path, $pattern, $message = ''): Nimmt an das ein oder mehrere DOM Elemente, die dem angegebenen CSS Selektor entsprechen, vorhanden sind, und das zumindest einer dem Regulären Ausdruck der in $pattern angegeben wurde, entspricht. Wenn eine $message vorhanden ist, wird diese jeder fehlgeschlagenen Ausnahmemeldung vorangestellt.
assertQueryCount($path, $count, $message = ''): Nimmt an das exakt $count DOM Elemente dem angegebenen CSS Selektor entsprechen. Wenn eine $message vorhanden ist, wird diese jeder fehlgeschlagenen Ausnahmemeldung vorangestellt.
assertQueryCountMin($path, $count, $message = ''): Nimmt an das zumindest $count DOM Element dem angegebenen CSS Selektor entsprechen. Wenn eine $message vorhanden ist, wird diese jeder fehlgeschlagenen Ausnahmemeldung vorangestellt. Achtung: Die Spezifizierung eines Wertes von 1 für $count ist das Gleiche wie die einfache Verwendung von assertQuery().
assertQueryCountMax($path, $count, $message = ''): Nimmt an das es nicht mehr als $count DOM Elemente gibt die dem angegebenen CSS Selektor entsprechen. Wenn eine $message vorhanden ist, wird diese jeder fehlgeschlagenen Ausnahmemeldung vorangestellt. Achtung: Die Spezifizierung eines Wertes von 1 für $count ist das Gleiche wie die einfache Verwendung von assertQuery().

Zusätzlich hat jede der obigen Methoden eine 'Not' Variante die eine negative Ausnahme anbietet: assertNotQuery(), assertNotQueryContentContains(), assertNotQueryContentRegex(), und assertNotQueryCount(). (Es ist zu beachten das die min und max Zählen keine dieser Varianten haben, was aus logischen Gründen so ist.)

XPath Ausnahmen

Einige Entwickler sind mit XPath vertrauter als mit CSS Selektoren, und deshalb werden für alle Query Ausnahmen auch XPath Varianten engeboten. Diese sind:

assertXpath($path, $message = '')
assertNotXpath($path, $message = '')
assertXpathContentContains($path, $match, $message = '')
assertNotXpathContentContains($path, $match, $message = '')
assertXpathContentRegex($path, $pattern, $message = '')
assertNotXpathContentRegex($path, $pattern, $message = '')
assertXpathCount($path, $count, $message = '')
assertNotXpathCount($path, $count, $message = '')
assertXpathCountMin($path, $count, $message = '')
assertNotXpathCountMax($path, $count, $message = '')

Umleitungs Ausnahmen

Oft wird eine Aktion umgeleitet. Statt der Umleitung zu folgen erlaubt es Zend_Test_PHPUnit_ControllerTestCase diese Umleitungen mit einer handvoll von Ausnahmen zu testen.

assertRedirect($message = ''): Nimmt einfach an das eine Umleitung stattgefunden hat.
assertNotRedirect($message = ''): Nimmt einfach an das keine Umleitung stattgefunden hat.
assertRedirectTo($url, $message = ''): Nimmt an das eine Umleitung stattgefunden hat, und das der Wert des Ziel Headers die angegebene $url ist.
assertNotRedirectTo($url, $message = ''): Nimmt an das eine Umleitung entweder NICHT stattgefunden hat, oder das der Wert des Ziel Headers NICHT die angegebene $url ist.
assertRedirectRegex($pattern, $message = ''): Nimmt an das eine Umleitung stattgefunden hat, und das der Wert des Ziel Headers dem durch $pattern angegebenen regulären Ausdruck entspricht.
assertNotRedirectRegex($pattern, $message = ''): Nimmt an das eine Umleitung entweder NICHT stattgefunden hat, oder das der Wert des Ziel Headers NICHT dem durch $pattern angegebenen regulären Ausdruck entspricht.

Antwort Header Ausnahmen

Zusätzlich zur Prüfung auf Umleitungs Header, ist es oft notwendig auf spezielle HTTP Antwort Codes und Header zu prüfen -- zum Beispiel, um zu erkennen um eine Aktion eine 404 oder 500 Antwort hervorruft, oder um sicherzustellen das JSON Antworten die entsprechenden Content-Type Header enthält. Die folgenden Ausnahmen sind vorhanden.

assertResponseCode($code, $message = ''): Nimmt an das die Antwort zum gegebenen HTTP Antwort Code geführt hat.
assertHeader($header, $message = ''): Nimmt an das die Antwort den gegebenen Header enthält.
assertHeaderContains($header, $match, $message = ''): Nimmt an das die Antwort den gegebenen Header enthält und das sein Inhalt den gegebenen String enthält.
assertHeaderRegex($header, $pattern, $message = ''): Nimmt an das die Antwort den gegebenen Header enthält und das sein Inhalt der gegebenen Regex entspricht.

Zusätzlich hat jede der obigen Ausnahmen eine 'Not' Variante für negative Ausnahmen.

Anfrage Ausnahmen

Es ist oft sinnvoll gegen die letzte Aktion, den Kontroller und das Modul zu prüfen; zusätzlich ist es möglich die genommene Route die prüfen. Die folgenden Ausnahmen können in diesen Fällen helfen:

assertModule($module, $message = ''): Nimmt an das das angegebene Modul in der letzten Dispatch Aktion verwendet wurde.
assertController($controller, $message = ''): Nimmt an das der angegebene Kontroller in der letzten ausgeführten Aktion ausgewählt wurde.
assertAction($action, $message = ''): Nimmt an das die angegebene Aktion zuletzt ausgeführt wurde.
assertRoute($route, $message = ''): Nimmt an das die angegebene benannte Route dem Router entsprochen hat.

Jede hat auch eine 'Not' Variante für negative Ausnahmen.

Beispiele

Zu wissen wir man die eigene Infrastruktur für Tests einstellt und wir Ausnahmen zu erstellen sind ist nur der halbe Kampf; jetzt ist es Zeit auf einige Testszenarien zu schauen und zu eruieren wie diese verwendet werden können.

Beispiel #2 Den UserController testen

Nehmen wir einen standard Task für eine Webseite an: Authentifizierung und Registrierung von Benutzern. In unserem Beispiel definieren wir einen UserController um das zu behandeln, und haben die folgenden Notwendigkeiten:

Wenn ein Benutzer nicht authentifiziert ist, wird er immer zur Login Seite des Kontrollers umgeleitet, unabhängig von der spezifizierten Aktion.
Die Login Formularseite wird beides zeigen, das Login Formular und das Registrations Formular.
Die angabe von ungültigen Anmeldedaten sollte in der Rückgabe des Login Formulars resultieren.
Das Ansehen der Anmeldedaten sollte in einer Umleitung zur Profilseite des Benutzers resultieren.
Die Profilseite sollte verändert werden um den Benutzernamen des Benutzers zu enthalten.
Authentifizierte Benutzer welche die Loginseite besuchen sollten zu Ihrer Profilseite umgeleitet werden.
Bei der Abmeldung, sollten ein Benutzer zur Loginseite umgeleitet werden.
Mit ungültigen Daten sollte die Registrierung fehlschlagen.

Wir können, und sollten zusätzliche Tests definieren, aber diese reichen für jetzt.

Für unsere Anwendung definieren wir ein Plugin, 'Initialisieren' es, damit es bei routeStartup() läuft. Das erlaubt es uns das Bootstrapping in einem OOP Interface zu kapseln, was auch einen einfachen Weg bietet um ein Callback zu ermöglichen. Schauen wir uns erstmals die Basics dieser Klasse an:

class Bugapp_Plugin_Initialize extends Zend_Controller_Plugin_Abstract
{
    /**
     * @var Zend_Config
     */
    protected static $_config;

    /**
     * @var string Aktuelle Umgebung
     */
    protected $_env;

    /**
     * @var Zend_Controller_Front
     */
    protected $_front;

    /**
     * @var string Pfad zum Root der Anwendung
     */
    protected $_root;

    /**
     * Constructor
     *
     * Umgebung, Root Pfad und Konfiguration initialisieren
     *
     * @param  string $env
     * @param  string|null $root
     * @return void
     */
    public function __construct($env, $root = null)
    {
        $this->_setEnv($env);
        if (null === $root) {
            $root = realpath(dirname(__FILE__) . '/../../../');
        }
        $this->_root = $root;

        $this->initPhpConfig();

        $this->_front = Zend_Controller_Front::getInstance();
    }

    /**
     * Route beginnen
     *
     * @return void
     */
    public function routeStartup(Zend_Controller_Request_Abstract $request)
    {
        $this->initDb();
        $this->initHelpers();
        $this->initView();
        $this->initPlugins();
        $this->initRoutes();
        $this->initControllers();
    }

    // Die Definition von Methoden würde hier folgen...
}

Das erlaubt es uns einen Bootstrap Callback wie folgt zu erstellen:

class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
    public function appBootstrap()
    {
        $controller = $this->getFrontController();
        $controller->registerPlugin(
            new Bugapp_Plugin_Initialize('development')
        );
    }

    public function setUp()
    {
        $this->bootstrap = array($this, 'appBootstrap');
        parent::setUp();
    }

    // ...
}

Sobald das fertig ist, können wir unsere Tests schreiben. Trotzdem, was ist mit den Tests die erfordern das der Benutzer angemeldet ist? Die einfache Lösung besteht darin das unsere Anwendungslogik das macht... und ein bischen trickst indem die resetRequest() und resetResponse() Methoden verwendet werden, die es uns erlauben eine andere Anfrage abzusetzen.

class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
    // ...

    public function loginUser($user, $password)
    {
        $this->request->setMethod('POST')
                      ->setPost(array(
                          'username' => $user,
                          'password' => $password,
                      ));
        $this->dispatch('/user/login');
        $this->assertRedirectTo('/user/view');
        $this->resetRequest()
             ->resetResponse();

        $this->request->setPost(array());

        // ...
    }

    // ...
}

Jetzt schreiben wir Tests:

class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
    // ...

    public function testCallWithoutActionShouldPullFromIndexAction()
    {
        $this->dispatch('/user');
        $this->assertController('user');
        $this->assertAction('index');
    }

    public function testLoginFormShouldContainLoginAndRegistrationForms()
    {
        $this->dispatch('/user');
        $this->assertQueryCount('form', 2);
    }

    public function testInvalidCredentialsShouldResultInRedisplayOfLoginForm()
    {
        $request = $this->getRequest();
        $request->setMethod('POST')
                ->setPost(array(
                    'username' => 'bogus',
                    'password' => 'reallyReallyBogus',
                ));
        $this->dispatch('/user/login');
        $this->assertNotRedirect();
        $this->assertQuery('form');
    }

    public function testValidLoginShouldRedirectToProfilePage()
    {
        $this->loginUser('foobar', 'foobar');
    }

    public function testAuthenticatedUserShouldHaveCustomizedProfilePage()
    {
        $this->loginUser('foobar', 'foobar');
        $this->request->setMethod('GET');
        $this->dispatch('/user/view');
        $this->assertNotRedirect();
        $this->assertQueryContentContains('h2', 'foobar');
    }

    public function
        testAuthenticatedUsersShouldBeRedirectedToProfileWhenVisitingLogin()
    {
        $this->loginUser('foobar', 'foobar');
        $this->request->setMethod('GET');
        $this->dispatch('/user');
        $this->assertRedirectTo('/user/view');
    }

    public function testUserShouldRedirectToLoginPageOnLogout()
    {
        $this->loginUser('foobar', 'foobar');
        $this->request->setMethod('GET');
        $this->dispatch('/user/logout');
        $this->assertRedirectTo('/user');
    }

    public function testRegistrationShouldFailWithInvalidData()
    {
        $data = array(
            'username' => 'This will not work',
            'email'    => 'this is an invalid email',
            'password' => 'Th1s!s!nv@l1d',
            'passwordVerification' => 'wrong!',
        );
        $request = $this->getRequest();
        $request->setMethod('POST')
                ->setPost($data);
        $this->dispatch('/user/register');
        $this->assertNotRedirect();
        $this->assertQuery('form .errors');
    }
}

Es ist zu beachten das die Tests knapp sind und, für die meisten von Ihnen, nicht den aktuellen Inhalt berücksichtigen. Stattdessen sehen Sie nach Teilen in der Anfrage -- Anfrage Codes und Header sowie DOM Knoten. Das erlaubt es schnell zu prüfen das die Strukturen wie erwartet sind -- und verhinter das die Tests jedesmal wenn der Site neue Inhalte hinzugefügt werden darin ersticken.

Es ist auch zu beachten das wir die Struktur des Dokuments in unseren Tests verwenden. Zum Beispiel schauen wir im letzten Test nach einer Form die einen Node mit der Klasse "errors" hat; das erlaubt es uns lediglich nach dem Vorhandensein von Form-Prüfungsfehlern zu testen, und uns keine Sorgen darüber zu machen warum spezielle Fehler überhaupt geworfen werden.

Diese Anwendung könnte eine Datenbank verwenden. Wenn dem so ist, muß man warscheinlich einige Grundlagen ändern um sicherzustellen das die Datenbank am Anfang jeden Tests, in einer unverfälschten, testbaren Konfiguration ist. PHPUnit bietet bereits Funktionalität um das sicherzustellen; » Lesen Sie darüber in der PHPUnit Dokumentation nach. Wir empfehlen eine separate Datenbank für das Testen zu verwenden statt der Produktionsdatenbank, und entweder eine SQLite Datei oder eine Datenbank im Speicher zu verwenden, da beide Optionen sehr performant sind, keinen separaten Server benötigen, und die meisten SQL Syntaxe verwenden können.

Einführung

Zend_Test
Referenzhandbuch für Programmierer

Zend_Text