| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143 |
- <?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> ;
- vous devrez ensuite <methodname>parent::setUp()</methodname> :
- </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>
|