# Amorcer votre TestCase

Comme noté dans l'exemple de login, tous les tests MVC doivent étendre `Zend_Test_PHPUnit_ControllerTestCase`. Cette classe étend elle-même `PHPUnit_Framework_TestCase`, 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.

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 `$bootstrap`.

Premièrement, et probablement le plus simple, créez simplement une instance de `Zend_Application` comme vous la souhaitez dans votre fichier `index.php`, et assignez la à la propriété `$bootstrap`. Typiquement, vous réaliserez ceci dans votre méthode `setUp()` ; vous devrez ensuite `parent::setUp()` :

    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();
        }
    }

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.

    class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
    {
        public $bootstrap = '/chemin/vers/amorcage/fichier.php'

        // ...
    }

Troisièmement, vous pouvez fournir un callback PHP qui doit être exécuter pour amorcer votre application. Cet exemple est montré dans l'exemple de login. Si le callback est une fonction ou une méthode statique, ceci peut être paramétrer au niveau de la classe :

    class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
    {
        public $bootstrap = array('App', 'bootstrap');

        // ...
    }

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

    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();
        }
    }

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

En utilisation normale, la méthode `setUp()` 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 `include()` du fichier spécifié dans `$bootstrap`, ou appeler le callback spécifié.

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

- Ne fournissez pas d'implémentations alternatives des objets "Request" et "Response" ; ils ne seront pas utilisés. `Zend_Test_PHPUnit_ControllerTestCase` utilise des objets de requête et de réponse personnalisés, respectivement `Zend_Controller_Request_HttpTestCase` et `Zend_Controller_Response_HttpTestCase`. 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.

- 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.

Une fois que votre application est amorcée, vous pouvez commencer à écrire vos tests.