Wie im Login-Beispiel gezeigt, sollten alle MVC-Testfälle Zend_Test_PHPUnit_ControllerTestCase erweitern. Diese Klasse ihrerseits erweitert PHPUnit_Framework_TestCase und gibt einem alle Strukturen und Zusicherungen, die man von PHPUnit erwartet -- sowie einiges an Scaffolding und Zusicherungen, die genau auf die Zend Framework MVC-Implementation zugeschnitten sind. Um die eigene MVC-Anwendung zu testen, muß diese ein Bootstrap ausführen. Es gibt verschiedene Wege, dies zu tun, wobei sich alle der öffentlichen $bootstrap-Eigenschaft bedienen. Erstens und möglicherweise am zielgerichtetsten kann man einfach eine Instanz von Zend_Application erstellen, wie man es in der index.php machen würde und diese der $bootstrap-Eigenschaft zuweisen. Normalerweise macht man das in der setUp()-Methode; anschließend muss man parent::setUp() aufrufen: bootstrap = new Zend_Application( 'testing', APPLICATION_PATH . '/configs/application.ini' ); parent::setUp(); } } ]]> Zweitens kann diese Eigenschaft so gesetzt werden, dass sie auf eine Datei zeigt. Wenn dieser Weg gewählt wird, sollte diese Datei nicht den Front-Controller ausführen, sondern stattdessen den Front-Controller konfigurieren und alles, was die Anwendung an speziellen Anforderungen benötigt. Drittens 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: In Fällen, in denen eine Objektinstanz notwendig ist, empfehlen wir die Durchführung in der eigenen setUp()-Methode: bootstrap = array($bootstrap, 'start'); parent::setUp(); } } ]]> Man beachte, dass parent::setUp() aufgerufen wird; das ist notwendig, da die setUp()-Methode von Zend_Test_PHPUnit_ControllerTestCase den Rest des Bootstrap-Prozesses durchführen wird (was den Aufruf des Callbacks einschließt). Während der normalen Anwendung wird die setUp()-Methode das Bootstrap der Anwendung ausführen. Dieser Prozess wird zunächst das Löschen der Umgebung enthalten, um einen sauberen Anfragestatus zu erhalten, das Zurücksetzen aller Plugins, Helfer und Antwortobjekte. Sobald das getan wurde, wird sie anschließend die Datei mit include() laden, die in $bootstrap angegeben ist 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 Antwortobjekte; diese werden nicht verwendet. Zend_Test_PHPUnit_ControllerTestCase verwendet eigene Anfrage- und Antwortobjekte, Zend_Controller_Request_HttpTestCase und Zend_Controller_Response_HttpTestCase. Diese Objekte stellen Methoden zur Verfügung, um die Anfrageumgebung gezielt aufzusetzen und um auf speziellem Weg die Antwort als Prüfgegenstand abzuholen. Man sollte nicht erwarten Server-spezifisches zu testen. Mit anderen Worten, die Tests garantieren nicht, dass der Code in einer speziellen Serverkonfiguration läuft, aber dass die Anwendung wie erwartet funktionieren sollte und der Router eine gegebene Anfrage routen kann. Aus diesem Grund sollten keine Server-spezifischen Header im Anfrageobjekt gesetzt werden. Sobald die Anwendung das Bootstrapping ausgeführt hat, kann damit begonnen werden, eigene Tests zu erstellen.