|
|
@@ -1,89 +1,89 @@
|
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
|
<!-- EN-Revision: 22236 -->
|
|
|
-<!-- Reviewed: no -->
|
|
|
+<!-- Reviewed: 22236 -->
|
|
|
<sect2 id="zend.test.phpunit.examples">
|
|
|
<title>Beispiele</title>
|
|
|
|
|
|
<para>
|
|
|
- Zu wissen wir man die eigene Infrastruktur für Tests einstellt und wir Behauptungen 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.
|
|
|
+ Zu wissen, wie man die eigene Infrastruktur für Tests einstellt und wie Zusicherungen zu
|
|
|
+ erstellen sind, ist nur die halbe Miete; jetzt ist es Zeit, sich einige Testszenarien
|
|
|
+ anzuschauen und herauszufinden, wie diese wirksam eingesetzt werden können.
|
|
|
</para>
|
|
|
|
|
|
<example id="zend.test.phpunit.examples.userController">
|
|
|
<title>Den UserController testen</title>
|
|
|
|
|
|
<para>
|
|
|
- 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:
|
|
|
+ Betrachten wir eine Standardaufgabe für eine Webseite: Authentifizierung und Registrierung
|
|
|
+ von Benutzern. In unserem Beispiel definieren wir einen UserController, um das zu
|
|
|
+ behandeln und haben die folgenden Anforderungen:
|
|
|
</para>
|
|
|
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>
|
|
|
- Wenn ein Benutzer nicht authentifiziert ist, wird er immer zur Login Seite des
|
|
|
- Controllers umgeleitet, unabhängig von der spezifizierten Aktion.
|
|
|
+ Wenn ein Benutzer nicht authentifiziert ist, wird er immer zur Login-Seite des
|
|
|
+ Controllers umgeleitet, unabhängig von der angeforderten Aktion.
|
|
|
</para>
|
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
|
<para>
|
|
|
- Die Login Formularseite wird beides zeigen, das Login Formular und das
|
|
|
- Registrations Formular.
|
|
|
+ Die Login-Formularseite wird sowohl das Login-Formular als auch das
|
|
|
+ Registrationsformular anzeigen.
|
|
|
</para>
|
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
|
<para>
|
|
|
- Die Angabe von ungültigen Anmeldedaten sollte in der Rückgabe des Login
|
|
|
- Formulars resultieren.
|
|
|
+ Die Angabe von ungültigen Anmeldedaten soll zur Anzeige des Login-Formulars
|
|
|
+ führen.
|
|
|
</para>
|
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
|
<para>
|
|
|
- Das Ansehen der Anmeldedaten sollte in einer Umleitung zur Profilseite des
|
|
|
- Benutzers resultieren.
|
|
|
+ Das Ansehen der Anmeldedaten soll zu einer Umleitung zur Profilseite des
|
|
|
+ Benutzers führen.
|
|
|
</para>
|
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
|
<para>
|
|
|
- Die Profilseite sollte verändert werden um den Benutzernamen des Benutzers zu
|
|
|
- enthalten.
|
|
|
+ Die Profilseite soll angepasst werden, um den Benutzernamen des Benutzers
|
|
|
+ anzuzeigen.
|
|
|
</para>
|
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
|
<para>
|
|
|
- Authentifizierte Benutzer welche die Loginseite besuchen sollten zu Ihrer
|
|
|
+ Authentifizierte Benutzer, welche die Loginseite besuchen, sollen zu ihrer
|
|
|
Profilseite umgeleitet werden.
|
|
|
</para>
|
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
|
<para>
|
|
|
- Bei der Abmeldung, sollten ein Benutzer zur Loginseite umgeleitet werden.
|
|
|
+ Bei der Abmeldung soll ein Benutzer zur Loginseite umgeleitet werden.
|
|
|
</para>
|
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
|
<para>
|
|
|
- Mit ungültigen Daten sollte die Registrierung fehlschlagen.
|
|
|
+ Mit ungültigen Daten soll die Registrierung fehlschlagen.
|
|
|
</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
|
|
|
<para>
|
|
|
- Wir können, und sollten zusätzliche Tests definieren, aber diese reichen für jetzt.
|
|
|
+ Wir können und sollten zusätzliche Tests definieren, aber diese reichen vorerst aus.
|
|
|
</para>
|
|
|
|
|
|
<para>
|
|
|
Für unsere Anwendung definieren wir ein Plugin, 'Initialisieren' es, damit es bei
|
|
|
- <methodname>routeStartup()</methodname> 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:
|
|
|
+ <methodname>routeStartup()</methodname> 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 Grundlagen dieser Klasse an:
|
|
|
</para>
|
|
|
|
|
|
<programlisting language="php"><![CDATA[
|
|
|
@@ -151,7 +151,7 @@ class Bugapp_Plugin_Initialize extends Zend_Controller_Plugin_Abstract
|
|
|
]]></programlisting>
|
|
|
|
|
|
<para>
|
|
|
- Das erlaubt es uns einen Bootstrap Callback wie folgt zu erstellen:
|
|
|
+ Das erlaubt es uns einen Bootstrap-Callback wie folgt zu erstellen:
|
|
|
</para>
|
|
|
|
|
|
<programlisting language="php"><![CDATA[
|
|
|
@@ -176,11 +176,11 @@ class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
|
|
|
]]></programlisting>
|
|
|
|
|
|
<para>
|
|
|
- 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
|
|
|
+ Sobald das fertig ist, können wir unsere Tests schreiben. Was ist jedoch mit den
|
|
|
+ Tests, die erfordern, dass der Benutzer angemeldet ist? Die einfache Lösung besteht darin,
|
|
|
+ dass unsere Anwendungslogik das macht... und ein bisschen trickst, indem die Methoden
|
|
|
<methodname>resetRequest()</methodname> und <methodname>resetResponse()</methodname>
|
|
|
- Methoden verwendet werden, die es uns erlauben eine andere Anfrage abzusetzen.
|
|
|
+ verwendet werden, die es uns erlauben eine andere Anfrage abzusetzen.
|
|
|
</para>
|
|
|
|
|
|
<programlisting language="php"><![CDATA[
|
|
|
@@ -294,31 +294,31 @@ class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
|
|
|
]]></programlisting>
|
|
|
|
|
|
<para>
|
|
|
- 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 zu beachten, dass die Tests knapp sind und größtenteils nicht den
|
|
|
+ aktuellen Inhalt suchen. Stattdessen suchen sie nach Teilen in der Anfrage --
|
|
|
+ Anfrage Codes und Header sowie DOM-Knoten. Das erlaubt es schnell zu prüfen, dass die
|
|
|
+ Strukturen wie erwartet sind -- und verhindern, dass die Tests jedesmal scheitern,
|
|
|
+ wenn der Site neue Inhalte hinzugefügt werden.
|
|
|
</para>
|
|
|
|
|
|
<para>
|
|
|
- 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
|
|
|
+ Es ist auch zu beachten, dass wir die Struktur des Dokuments in unseren Tests verwenden.
|
|
|
+ Zum Beispiel suchen wir im letzten Test nach einer Form, die einen Knoten der Klasse
|
|
|
+ "errors" hat; das erlaubt es uns lediglich auf das Vorhandensein von
|
|
|
+ Form-Prüfungsfehlern zu testen und uns keine Sorgen darüber zu machen, warum spezielle
|
|
|
Fehler überhaupt geworfen werden.
|
|
|
</para>
|
|
|
|
|
|
<para>
|
|
|
Diese Anwendung <emphasis>könnte</emphasis> 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
|
|
|
+ muss man wahrscheinlich einige Grundlagen ändern um sicherzustellen, dass die Datenbank am
|
|
|
+ Anfang jedes Tests in einer unverfälschten, testbaren Konfiguration ist. PHPUnit bietet
|
|
|
bereits Funktionalität um das sicherzustellen; <ulink
|
|
|
url="http://www.phpunit.de/manual/3.4/en/database.html">Lesen Sie darüber in
|
|
|
- der PHPUnit Dokumentation nach</ulink>. Wir empfehlen eine separate Datenbank für das
|
|
|
- Testen zu verwenden statt der Produktionsdatenbank, und entweder eine SQLite Datei oder
|
|
|
+ der PHPUnit-Dokumentation nach</ulink>. 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 <acronym>SQL</acronym> Syntax verwenden
|
|
|
+ separaten Server benötigen und die meisten <acronym>SQL</acronym>-Syntax verwenden
|
|
|
können.
|
|
|
</para>
|
|
|
</example>
|
loeffler.de