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 (143 lines) | stat: -rw-r--r-- 6,178 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
<?xml version="1.0" encoding="UTF-8"?>
<!-- EN-Revision: 24249 -->
<!-- Reviewed: no -->
<sect2 id="zend.test.phpunit.bootstrapping">
    <title>Amorcer votre TestCase</title>

    <para>
        Comme noté dans <link linkend="zend.test.phpunit.loginexample">l'exemple de
        login</link>, tous les tests <acronym>MVC</acronym> doivent étendre
        <classname>Zend_Test_PHPUnit_ControllerTestCase</classname>. Cette classe étend elle-même
        <classname>PHPUnit_Framework_TestCase</classname>, et vous fournit donc toute la structure et les
        assertions que vous attendez de PHPUnit - ainsi que quelques échafaudages et assertions
        spécifiques à l'implémentation <acronym>MVC</acronym> de Zend Framework.
    </para>

    <para>
        Si vous voulez tester votre application <acronym>MVC</acronym>, vous devez d'abord l'amorcer
        ("bootstrap"). Il existe plusieurs manières pour faire ceci, toutes celles-ci s'articulent
        autour de la propriété publique <varname>$bootstrap</varname>.
    </para>

     <para>
        Premièrement, et probablement le plus simple, créez simplement une instance de
        <classname>Zend_Application</classname> comme vous la souhaitez dans votre fichier
        <filename>index.php</filename>, et assignez la à la propriété <varname>$bootstrap</varname>.
        Typiquement, vous réaliserez ceci dans votre méthode <methodname>setUp()</methodname>&#160;;
        vous devrez ensuite <methodname>parent::setUp()</methodname>&#160;:
    </para>

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

    <para>
        Deuxièmement, vous pouvez paramétrer cette propriété pour qu'elle pointe vers un
        fichier. Si vous faîtes ceci, le fichier ne doit pas distribuer le contrôleur frontal, mais
        seulement paramétrer celui-ci et faire tout réglage spécifique à votre application.
    </para>

    <programlisting language="php"><![CDATA[
class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
    public $bootstrap = '/chemin/vers/amorcage/fichier.php'

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

    <para>
        Troisièmement, vous pouvez fournir un callback <acronym>PHP</acronym> qui doit être exécuter pour amorcer
        votre application. Cet exemple est montré dans <link
        linkend="zend.test.phpunit.loginexample">l'exemple de login</link>. Si le callback est une
        fonction ou une méthode statique, ceci peut être paramétrer au niveau de la classe :
    </para>

    <programlisting language="php"><![CDATA[
class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
    public $bootstrap = array('App', 'bootstrap');

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

    <para>
        Dans le cas où une instance d'objet est nécessaire, nous recommandons de réaliser ceci
        dans votre méthode <methodname>setUp()</methodname> :
    </para>

    <programlisting language="php"><![CDATA[
class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
    public function setUp()
    {
        // Utilisez la méthode "start" de l'instance d'objet Bootstrap :
        $bootstrap = new Bootstrap('test');
        $this->bootstrap = array($bootstrap, 'start');
        parent::setUp();
    }
}
]]></programlisting>

    <para>
        Notez l'appel de <methodname>parent::setUp()</methodname>; ceci est nécessaire puisque la méthode
        <methodname>setUp()</methodname> de <classname>Zend_Test_PHPUnit_ControllerTestCase</classname>
        exécutera le reste du processus d'amorçage (incluant l'appel du callback).
    </para>

    <para>
        En utilisation normale, la méthode <methodname>setUp()</methodname> amorcera l'application. Ce
        premier processus inclue le nettoyage de l'environnement pour rendre un état de requête
        propre, va réinitialiser tout plugins ou aides, va réinitialiser l'instance du contrôleur
        frontal, et créer de nouveaux objets de requête et de réponse. Une fois ceci fait, la
        méthode va faire un <methodname>include()</methodname> du fichier spécifié dans <varname>$bootstrap</varname>,
        ou appeler le callback spécifié.
    </para>

    <para>
        L'amorçage doit être le proche possible de ce que fera réellement votre application.
        Cependant, il y a plusieurs avertissements :
    </para>

    <itemizedlist>
        <listitem>
            <para>
                Ne fournissez pas d'implémentations alternatives des objets "Request" et
                "Response" ; ils ne seront pas utilisés.
                <classname>Zend_Test_PHPUnit_ControllerTestCase</classname> utilise des objets de
                requête et de réponse personnalisés, respectivement
                <classname>Zend_Controller_Request_HttpTestCase</classname> et
                <classname>Zend_Controller_Response_HttpTestCase</classname>. Ces objets fournissent
                des méthodes pour paramétrer l'environnement de requête dans le but souhaité, et
                récupérer les objets de réponse façonnés.
            </para>
        </listitem>

        <listitem>
            <para>
                N'espérez pas faire des tests spécifiques de serveur. Autrement dit, ces tests
                ne garantissent pas que le code va s'exécuter sur un serveur avec une configuration
                spécifique, mais simplement que l'application va fonctionner comme souhaité si le
                routeur est capable de router une requête donnée. À cet effet, ne paramétrez pas
                d'en-têtes spécifiques au serveur dans l'objet de requête.
            </para>
        </listitem>
    </itemizedlist>

    <para>
        Une fois que votre application est amorcée, vous pouvez commencer à écrire vos
        tests.
    </para>
</sect2>