Zend_Test_PHPUnitZend_Test_PHPUnit fournit un TestCase pour les applications MVC qui contient des assertions qui permettent de tester toute une variété de responsabilités. La manière la plus facile de comprendre ce qui peut être fait est de regarder l'exemple suivant. Example #1 Exemple d'un TestCase d'une application de login L'exemple suivant est un simple test pour un contrôleur UserController permettant de vérifier différentes choses :
Cet exemple particulier suppose différentes choses. Premièrement, la majeure partie de notre fichier d'amorçage a été déplacé dans un plugin. Ceci simplifie le paramétrage dans le cas des tests en spécifiant rapidement votre environnement, et ainsi vous permet d'amorcer votre application en une seule ligne. Ensuite, notre exemple suppose que le chargement automatique ("autoload") est activé donc nous n'avons pas à nous soucier de charger les classes appropriées (comme le bon contrôleur, le bon plugin, etc.)
Cet exemple pourrait être écrit plus simplement : toutes les assertions ne sont pas nécessaires et sont fournies seulement à titre d'illustration. Cependant, il montre bien combien il est simple de tester vos applications. Amorcer votre TestCaseComme 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() :
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.
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 :
Dans le cas où une instance d'objet est nécessaire, nous recommandons de réaliser ceci dans votre méthode 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 :
Une fois que votre application est amorcée, vous pouvez commencer à écrire vos tests. Tester vos contrôleurs et vos applications MVCUne fois , votre fichier d'amorçage en place, vous pouvez commencer à tester. Tester est typiquement ce que vous auriez pu faire avec une suite de test PHPUnit ("test suite"), avec quelques petites différences mineures. Premièrement, vous devez distribuer l'URL à tester en utilisant la méthode dispatch() de TestCase :
Il y a des moments, cependant, où vous devez fournir des informations supplémentaires - des variables GET et POST, des informations de COOKIE, etc. Vous pouvez peupler la requête avec ces informations :
Maintenant que la requête est construite, il est temps de créer des assertions. Controller Tests and the Redirector Action HelperImportant
The redirect action helper issues an exit() statement when using the method gotoAndExit() and will then obviously also stops a test running for this method. For testability of your application dont use that method on the redirector! Due to its nature the redirector action helper plugin issues a redirect and exists after this. Because you cannot test parts of an application that issue exit calls Zend_Test_PHPUnit_ControllerTestCase automatically disables the exit part of the redirector which can cause different behaviours in tests and the real application. To make sure redirect work correctly you should it them in the following way:
Important
Depending on your application this is not enough as additional action, preDispatch() or postDispatch() logic might be executed. This cannot be handled in a good way with Zend Test currently. AssertionsLes assertions sont le coeur des tests unitaires; vous les utilisez pour vérifier que le résultat est bien celui que vous attendiez. A cette fin, Zend_Test_PHPUnit_ControllerTestCase fournit un certain nombre d'assertions pour simplifier le test de vos applications et contrôleurs MVC. Les assertions par sélecteurs CSSLes sélecteurs CSS sont une manière simple de vérifier que certaines constructions sont bien présentes dans le contenu de votre réponse. Cela rend aussi plus simple de s'assurer que les éléments nécessaires pour les librairies Javascript et/ou l'intégration d'AJAX sont présents ; la plupart des bibliothèques Javascript fournissent des mécanismes pour charger des éléments DOM sur la base des sélecteurs CSS, ainsi la syntaxe sera identique.
Cette fonctionnalité est fournie via Zend_Dom_Query, et intégré à un jeu d'assertions de type
"
De plus, toutes les méthodes ci-dessus possèdent une variante " Les assertions XPathCertains développeurs sont plus familiers avec XPath qu'avec des sélecteurs CSS, ainsi les variantes XPath des toutes les assertions Query sont aussi fournies. Il s'agit de :
Les assertions de redirectionsSouvent une action va redirigé le visiteur. Plutôt que de suivre cette redirection, Zend_Test_PHPUnit_ControllerTestCase vous permet de tester ces redirections avec un jeu d'assertions :
Les assertions d'en-têtes de réponses
En plus de vérifier les en-têtes de redirection, vous avez souvent besoin de
vérifier des codes de réponse HTTP et des en-têtes spécifiques - par exemple, pour
déterminer si une action entraînera une réponse 404 ou 500, ou pour s'assurer qu'une
réponse JSON contient bien l'en-tête
De plus, toutes les méthodes ci-dessus possèdent une variante " Les assertions de requêtesIl est souvent pratique de vérifier l'action, le contrôleur et le module dernièrement exécuté ; ou, vous pouvez vouloir vérifier quelle route a été utilisée. Les assertions suivantes peuvent vous aider dans ce cas :
De plus, toutes les méthodes ci-dessus possèdent une variante " ExemplesSavoir comment configurer votre infrastructure de tests et comment faire des assertions est seulement la moitié du travail ; maintenant il est temps de commencer à regarder quelques scénarios réels de test pour voir comment vous pouvez les étendre. Example #2 Test d'un contrôleur "UserController"
Considérons une tâche habituelle d'un site Web : l'authentification et
l'enregistrement d'utilisateurs. Dans notre exemple, nous avons défini un contrôleur
"
Nous pourrions, et devrions définir d'autres tests, mais ceux-ci suffiront pour l'instant.
Pour notre application, nous définirons un plugin "
Ceci nous permet de créer un callback d'amorçage comme ce qui suit :
Une fois ceci en place, nous pouvons écrire nos tests. Cependant, combien de ces tests nécessiteront qu'un utilisateur soit connecté ? La solution la plus simple est d'utiliser la logique de votre application pour faire ceci... et d'esquiver un peu par l'utilisation des méthodes resetResponse() et resetResponse(), qui vous permettront de distribuer une nouvelle requête.
Écrivons maintenant les tests :
Notez que ces tests sont laconiques, et, pour la plupart, ne recherchent pas le contenu réel. Au lieu de cela, ils recherchent des objets construits dans la réponse - codes et en-têtes de réponse, et noeuds DOM. Ceci vous permet de vérifier que la structure est comme prévue - sans entraîner un échec dans vos tests à chaque fois qu'un contenu est ajouté au site. Notez également que nous utilisons la structure du document dans nos essais. Par exemple, dans le test final, nous recherchons un formulaire qui a un noeud avec la classe "errors" ; ceci nous permet de déterminer simplement la présence des erreurs de validation de formulaire, et sans nous inquiéter de quelles erreurs spécifiques pourraient avoir été levées. Cette application peut utiliser une base de données. Si oui, vous aurez besoin probablement d'un certain échafaudage pour s'assurer que la base de données est dans une configuration initiale et testable au début de chaque essai. PHPUnit fournit déjà une fonctionnalité pour faire ceci ; » lisez ceci dans la documentation PHPUnit. Nous recommandons d'utiliser une base de données séparée pour les tests et pour la production, et recommandons en particulier d'employer un fichier SQLite ou une base de données en mémoire, d'autant que les deux options s'exécutent très bien, sans nécessité d'un serveur séparé, et peuvent utiliser la plupart de la syntaxe SQL
|