Zend_Test-PHPUnit-Bootstrapping.xml 5.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <!-- EN-Revision: 15617 -->
  3. <!-- Reviewed: no -->
  4. <sect2 id="zend.test.phpunit.bootstrapping">
  5. <title>Amorcer votre TestCase</title>
  6. <para>
  7. Comme noté dans <link linkend="zend.test.phpunit.loginexample">l'exemple de
  8. login</link>, tous les tests MVC doivent étendre
  9. <classname>Zend_Test_PHPUnit_ControllerTestCase</classname>. Cette classe étend elle-même
  10. <code>PHPUnit_Framework_TestCase</code>, et vous fournit donc toute la structure et les
  11. assertions que vous attendez de PHPUnit - ainsi que quelques échafaudages et assertions
  12. spécifiques à l'implémentation MVC de Zend Framework.
  13. </para>
  14. <para>
  15. Si vous voulez tester votre application MVC, vous devez d'abord l'amorcer
  16. ("bootstrap"). Il existe plusieurs manières pour faire ceci, toutes celles-ci s'articulent
  17. autour de la propriété publique <code>$bootstrap</code>.
  18. </para>
  19. <para>
  20. Premièrement, vous pouvez paramétrer cette propriété pour qu'elle pointe vers un
  21. fichier. Si vous faîtes ceci, le fichier ne doit pas distribuer le contrôleur frontal, mais
  22. seulement paramétrer celui-ci et faire tout réglage spécifique à votre application.
  23. </para>
  24. <programlisting language="php"><![CDATA[
  25. class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
  26. {
  27. public $bootstrap = '/chemin/vers/amorcage/fichier.php'
  28. // ...
  29. }
  30. ]]></programlisting>
  31. <para>
  32. Deuxièmement, vous pouvez fournir un callback PHP qui doit être exécuter pour amorcer
  33. votre application. Cet exemple est montré dans <link
  34. linkend="zend.test.phpunit.loginexample">l'exemple de login</link>. Si le callback est une
  35. fonction ou une méthode statique, ceci peut être paramétrer au niveau de la classe :
  36. </para>
  37. <programlisting language="php"><![CDATA[
  38. class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
  39. {
  40. public $bootstrap = array('App', 'bootstrap');
  41. // ...
  42. }
  43. ]]></programlisting>
  44. <para>
  45. Dans le cas où une instance d'objet est nécessaire, nous recommandons de réaliser ceci
  46. dans votre méthode <code>setUp()</code> :
  47. </para>
  48. <programlisting language="php"><![CDATA[
  49. class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
  50. {
  51. public function setUp()
  52. {
  53. // Utilisez la méthode "start" de l'instance d'objet Bootstrap :
  54. $bootstrap = new Bootstrap('test');
  55. $this->bootstrap = array($bootstrap, 'start');
  56. parent::setUp();
  57. }
  58. }
  59. ]]></programlisting>
  60. <para>
  61. Notez l'appel de <code>parent::setUp()</code>; ceci est nécessaire puisque la méthode
  62. <code>setUp()</code> de <classname>Zend_Test_PHPUnit_Controller_TestCase</classname>
  63. exécutera le reste du processus d'amorçage (incluant l'appel du callback).
  64. </para>
  65. <para>
  66. En utilisation normale, la méthode <code>setUp()</code> amorcera l'application. Ce
  67. premier processus inclue le nettoyage de l'environnement pour rendre un état de requête
  68. propre, va réinitialiser tout plugins ou aides, va réinitialiser l'instance du contrôleur
  69. frontal, et créer de nouveaux objets de requête et de réponse. Une fois ceci fait, la
  70. méthode va faire un <code>include</code> du fichier spécifié dans <code>$bootstrap</code>,
  71. ou appeler le callback spécifié.
  72. </para>
  73. <para>
  74. L'amorçage doit être le proche possible de ce que fera réellement votre application.
  75. Cependant, il y a plusieurs avertissements :
  76. </para>
  77. <itemizedlist>
  78. <listitem>
  79. <para>
  80. Ne fournissez pas d'implémentations alternatives des objets "Request" et
  81. "Response" ; ils ne seront pas utilisés.
  82. <classname>Zend_Test_PHPUnit_Controller_TestCase</classname> utilise des objets de
  83. requête et de réponse personnalisés, respectivement
  84. <classname>Zend_Controller_Request_HttpTestCase</classname> et
  85. <classname>Zend_Controller_Response_HttpTestCase</classname>. Ces objets fournissent
  86. des méthodes pour paramétrer l'environnement de requête dans le but souhaité, et
  87. récupérer les objets de réponse façonnés.
  88. </para>
  89. </listitem>
  90. <listitem>
  91. <para>
  92. N'espérez pas faire des tests spécifiques de serveur. Autrement dit, ces tests
  93. ne garantissent pas que le code va s'exécuter sur un serveur avec une configuration
  94. spécifique, mais simplement que l'application va fonctionner comme souhaité si le
  95. routeur est capable de router une requête donnée. À cet effet, ne paramétrez pas
  96. d'en-têtes spécifiques au serveur dans l'objet de requête.
  97. </para>
  98. </listitem>
  99. </itemizedlist>
  100. <para>
  101. Une fois que votre application est amorcée, vous pouvez commencer à écrire vos
  102. tests.
  103. </para>
  104. </sect2>