Action Tests

Bei Action Tests geht es darum, eine bestimmte Action zu durchlaufen und das Ergebnis (Datenbank, HTML, View-Assigns) zu bewerten.
Action Tests werden innerhalb des Moduls im Test Ordner angelegt. Hier ist sowohl eine Suite.php Datei, als auch Unterordner für Models und Actions vorhanden.

Es existieren wie für die Actions auch, Abstraktionen für CRUD(L). Ein Action Test ist ein erweiterter TestCase, der sich automatisch um das Resetten und Dispatchen kümmert, um die Unabhängigkeit einzelner Tests zu gewährleisten. Außerdem ist ein Routing Test in der Abstraktion vorhanden, der sicherstellt, dass der Test auch wirklich in die angeforderte Action routet.

Die erste Quelle für das Schreiben von Tests ist das Kickstart Modul. Hier sind bereits eine Reihe von Tests implementiert. Ein Action-Test erweitert die Zend_Test_PHPUnit_ControllerTestCase Klasse, was bedeutet, dass alle asserts, die von Zend bekannt sind ebenfalls funktionieren. Das Routing wird automatisch über den Namen der Action/des Tests vorgenommen.

Asserts

Es gibt ein paar neue, nützliche Asserts, die für Actions Tests genutzt werden können:
assertErrorstackEmpty()
Keine Errorstack Einträge vorhanden.
assertErrorstackError()
Errorstack Fehler vorhanden.
assertMailCount($cnt)
Es hätten $cnt mails versendet werden sollen.

Dispatching

Nachdem das Mocking stattgefunden hat, kann die Action schließlich dispatcht werden. Dies geschieht via
$this->dispatch();

Wenn die aufzurufende URL nicht der des Tests entspricht, kann optional auch eine URL mit übergeben werden.
$this->dispatch('/MyUrl.htm');

Request Parameter werden am einfachsten vorher über das Request Objekt mitgegeben.
$this->getRequest()->setPost('myvar', 'MyValue');


Login

Manche Actions benötigen einen gültigen Login, um erfolgreich zu laufen. Hierzu wird einfach vor dem Dispatchen die Methode Login aufgerufen.
$this->login();

$this->dispatch();


Mocking

Datenbankmocking via Model
Die erste Möglichkeit Daten in die Datenbank einzutragen ist mittels Model. Hierzu holt man sich das Model und operiert wie gewohnt darauf.

Datenbankmocking Quick'n'Dirty
Eine weitere Möglichkeit Daten in die Datenbank zu füllen ist direkt per SQL. Dies ist wenig abstrakt, dafür geht es relativ schnell. Hier sollte man aufpassen, dass man sich durch ein ungeschicktes Query nicht den Test sabotiert.

Datums-Mocking
Das Mocken von bestimmten Daten und Uhrzeiten ist leider nicht ganz einfach. In der Programmierung muss darauf geachtet werden, dass nicht einfach ein neues Zend_Date erzeugt wird, sondern via Frontcontroller o.Ä. immer auf das gleiche Zend_Date objekt zugegriffen wird (siehe Testing Einführung - Testbarkeit).

Broker Mocking / Path Mocking
Das Mocken des Brokers oder Path ist für Action Tests leider nicht möglich, da einmal geladene Objekte für weitere Tests nicht mehr entladen werden können. Somit wäre ein einmal ausgetauschter Broker für alle Tests gültig, was dem Prinzip der Unabhängigkeit der Test voneinander widerspricht.

Mocks erstellen
Beim Erstellen eines Mocks muss darauf geachtet werden, dass dieser unbedingt eine Methode zum Reset beinhaltet und diese stets vorher aufgerufen wird. Nur so kann die Unabhängigkeit der Tests gewährleistet werden.

Beispiel

<?php
/**

* Dispatch through an action an do some asserts

*/

public function testBlogForm() {

    /* Dispatch the action */

    $this->dispatch();

    $this->assertResponseCode('200');



    /* check if a form is rendered */

    $this->assertXpath('//form');

}
?>


Kuborgh GmbH

Hamburg 040 819 773 770 Köln 0221 276 66 96 info@kuborgh.de www.kuborgh.de

RedSpark Community

RedSpark Community

Community Website
RedSpark Apps

RedSpark Apps

Zur Übersicht
RedSpark Download

RedSpark Basispaket

Zum Download
Key facts