| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121 |
- <?xml version="1.0" encoding="UTF-8"?>
- <!-- EN-Revision: 17175 -->
- <!-- Reviewed: no -->
- <sect2 id="zend.test.phpunit.bootstrapping">
- <title>Bootstrapping der eigenen TestCases</title>
- <para>
- Wie im <link linkend="zend.test.phpunit.loginexample">Login Beispiel</link> gezeigt sollten
- alle <acronym>MVC</acronym> Testcases
- <classname>Zend_Test_PHPUnit_ControllerTestCase</classname> erweitern. Diese Klasse
- ihrerseits erweitert <code>PHPUnit_Framework_TestCase</code>, und gibt einem alle Strukturen
- und Ausnahmen die man von PHPUnit erwartet -- sowie einiges an Scaffolding und Ausnahme
- spezifisches der Zend Framework <acronym>MVC</acronym> Implementation.
- </para>
- <para>
- Um die eigene <acronym>MVC</acronym> Anwendung zu testen muß diese ein Bootstrap ausführen.
- Es gibt verschiedene Wege um das zu tun, wobei alle von Ihnen sich der öffentlichen
- <varname>$bootstrap</varname> Eigenschaft bedienen.
- </para>
- <para>
- Zuerst kann diese Eigenschaft so gesetzt werden das Sie auf eine Datei zeigt. Wenn das getan
- wurde sollte diese Datei <emphasis>nicht</emphasis> den Front Controller ausführen, aber
- stattdessen den Front Controller konfigurieren und alles was die Anwendung an speziellen
- Dingen benötigt.
- </para>
- <programlisting language="php"><![CDATA[
- class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
- {
- public $bootstrap = '/path/to/bootstrap/file.php'
- // ...
- }
- ]]></programlisting>
- <para>
- Zweitens kann ein <acronym>PHP</acronym> Callback angegeben werden der nach dem Bootstrap
- der Anwendung ausgeführt wird. Diese Methode kann im <link
- linkend="zend.test.phpunit.loginexample">Login Beispiel</link> gesehen werden. Wenn das
- Callback eine Funktion oder statische Methode ist, könnte Sie auch in der Klasse gesetzt
- werden:
- </para>
- <programlisting language="php"><![CDATA[
- class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
- {
- public $bootstrap = array('App', 'bootstrap');
- // ...
- }
- ]]></programlisting>
- <para>
- In Fällen in denen eine Objekt Instanz notwendig ist, empfehlen wir die Durchführung in der
- eigenen <methodname>setUp()</methodname> Methode:
- </para>
- <programlisting language="php"><![CDATA[
- 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();
- }
- }
- ]]></programlisting>
- <para>
- Beachte das <methodname>parent::setUp()</methodname> aufgerufen wird; das ist notwendig, da
- die <methodname>setUp()</methodname> Methode von
- <classname>Zend_Test_PHPUnit_Controller_TestCase</classname> die Erinnerung des Bootstrap
- Prozesses durchführen wird (was den Aufruf des Callbacks inkludiert).
- </para>
- <para>
- Wärend der normalen Anwendung wird die <methodname>setUp()</methodname> 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
- <methodname>laden(include)</methodname> die in <varname>$bootstrap</varname> spezifiziert
- wurde, oder den spezifizierten Callback aufrufen.
- </para>
- <para>
- Das Bootstrappen sollte so nahe wie möglich daran sein wie die Anwendung das Bootstrap
- durchführt. Trotzdem gibt es einige Fallstricke:
- </para>
- <itemizedlist>
- <listitem><para>
- Wir bieten keine alternative Implementierung der Anfrage und Antwort Objekte; diese
- werden nicht verwendet. <classname>Zend_Test_PHPUnit_Controller_TestCase</classname>
- verwendet eigene Anfrage und Antwort Objekte,
- <classname>Zend_Controller_Request_HttpTestCase</classname> und
- <classname>Zend_Controller_Response_HttpTestCase</classname>. Diese Objekte bieten
- Methoden für das Konfigurieren der Anfrageumgebung auf gezieltem Wege an, und dem Holen
- von Antwort Artefakten auf speziellem Weg.
- </para></listitem>
- <listitem><para>
- 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.
- </para></listitem>
- </itemizedlist>
- <para>
- Sobald die Anwendung das Bootstrapping ausgeführt hat, kann damit begonnen werden eigene
- Tests zu erstellen.
- </para>
- </sect2>
- <!--
- vim:se ts=4 sw=4 et:
- -->
|