File: Zend_Test-PHPUnit-Bootstrapping.xml

package info (click to toggle)
zendframework 1.12.9%2Bdfsg-2
  • links: PTS, VCS
  • area: main
  • in suites: jessie-kfreebsd
  • size: 133,584 kB
  • sloc: xml: 1,311,829; php: 570,173; sh: 170; makefile: 125; sql: 121
file content (145 lines) | stat: -rw-r--r-- 6,183 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
<?xml version="1.0" encoding="UTF-8"?>
<!-- EN-Revision: 24249 -->
<!-- Reviewed: 20807 -->
<sect2 id="zend.test.phpunit.bootstrapping">
    <title>Bootstrapping der eigenen Testfälle</title>

    <para>
        Wie im <link linkend="zend.test.phpunit.loginexample">Login-Beispiel</link> gezeigt, sollten
        alle <acronym>MVC</acronym>-Testfälle
        <classname>Zend_Test_PHPUnit_ControllerTestCase</classname> erweitern. Diese Klasse
        ihrerseits erweitert <classname>PHPUnit_Framework_TestCase</classname> und gibt einem alle
        Strukturen und Zusicherungen, die man von PHPUnit erwartet -- sowie einiges an Scaffolding und
        Zusicherungen, die genau auf die Zend Framework <acronym>MVC</acronym>-Implementation zugeschnitten sind.
    </para>

    <para>
        Um die eigene <acronym>MVC</acronym>-Anwendung zu testen, muß diese ein Bootstrap ausführen.
        Es gibt verschiedene Wege, dies zu tun, wobei sich alle der öffentlichen
        <varname>$bootstrap</varname>-Eigenschaft bedienen.
    </para>

    <para>
        Erstens und möglicherweise am zielgerichtetsten kann man einfach eine Instanz von
        <classname>Zend_Application</classname> erstellen, wie man es in der
        <filename>index.php</filename> machen würde und diese der <varname>$bootstrap</varname>-Eigenschaft
        zuweisen. Normalerweise macht man das in der <methodname>setUp()</methodname>-Methode;
        anschließend muss man <methodname>parent::setUp()</methodname> aufrufen:
    </para>

    <programlisting language="php"><![CDATA[
class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
    public function setUp()
    {
        // Zuordnen und Initiieren in einem Schritt:
        $this->bootstrap = new Zend_Application(
            'testing',
            APPLICATION_PATH . '/configs/application.ini'
        );
        parent::setUp();
    }
}
]]></programlisting>

    <para>
        Zweitens kann diese Eigenschaft so gesetzt werden, dass sie auf eine Datei zeigt. Wenn dieser
        Weg gewählt wird, sollte diese Datei <emphasis>nicht</emphasis> den Front-Controller ausführen,
        sondern stattdessen den Front-Controller konfigurieren und alles, was die Anwendung an
        speziellen Anforderungen benötigt.
    </para>

    <programlisting language="php"><![CDATA[
class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
    public $bootstrap = '/path/to/bootstrap/file.php'

    // ...
}
]]></programlisting>

    <para>
        Drittens 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 Objektinstanz 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-Objektinstanz:
        $bootstrap = new Bootstrap('test');
        $this->bootstrap = array($bootstrap, 'start');
        parent::setUp();
    }
}
]]></programlisting>

    <para>
        Man beachte, dass <methodname>parent::setUp()</methodname> aufgerufen wird; das ist notwendig, da
        die <methodname>setUp()</methodname>-Methode von
        <classname>Zend_Test_PHPUnit_ControllerTestCase</classname> den Rest des Bootstrap-Prozesses
        durchführen wird (was den Aufruf des Callbacks einschließt).
    </para>

    <para>
        Während der normalen Anwendung wird die <methodname>setUp()</methodname>-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
        <methodname>include()</methodname> laden, die in <varname>$bootstrap</varname> angegeben
        ist 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 Antwortobjekte; diese
                werden nicht verwendet. <classname>Zend_Test_PHPUnit_ControllerTestCase</classname>
                verwendet eigene Anfrage- und Antwortobjekte,
                <classname>Zend_Controller_Request_HttpTestCase</classname> und
                <classname>Zend_Controller_Response_HttpTestCase</classname>. Diese Objekte stellen
                Methoden zur Verfügung, um die Anfrageumgebung gezielt aufzusetzen und um auf
                speziellem Weg die Antwort als Prüfgegenstand abzuholen.
            </para>
        </listitem>

        <listitem>
            <para>
                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.
            </para>
        </listitem>
    </itemizedlist>

    <para>
        Sobald die Anwendung das Bootstrapping ausgeführt hat, kann damit begonnen werden, eigene
        Tests zu erstellen.
    </para>
</sect2>