repo_zf1/documentation/manual/fr/module_specs/Zend_Test-PHPUnit-Bootstrapping.xml

<!-- EN-Revision: 11497 -->
<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 MVC
    doivent étendre <classname>Zend_Test_PHPUnit_ControllerTestCase</classname>. Cette classe étend elle-même
    <code>PHPUnit_Framework_TestCase</code>, 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 MVC de Zend
    Framework.</para>

    <para>Si vous voulez tester votre application MVC, 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
    <code>$bootstrap</code>.</para>

    <para>Premièrement, 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 role="php"><![CDATA[
class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
    public $bootstrap = '/chemin/vers/amorcage/fichier.php'

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

    <para>Deuxièmement, vous pouvez fournir un callback PHP 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 role="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
    <code>setUp()</code> :</para>

    <programlisting role="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 <code>parent::setUp()</code>; ceci est nécessaire puisque la méthode <code>setUp()</code> de
    <classname>Zend_Test_PHPUnit_Controller_TestCase</classname> exécutera le reste du processus d'amorçage (incluant l'appel du
    callback).</para>

    <para>En utilisation normale, la méthode <code>setUp()</code> 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 <code>include</code> du fichier spécifié dans <code>$bootstrap</code>, 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_Controller_TestCase</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>