PHPUnit – Tester les Erreurs, Warnings et Notices

Voici un billet très court afin de présenter la façon dont je teste les méthodes qui génèrent des erreurs, warnings et notices dans mes tests unitaires avec PHPUnit.

La méthode classique est d’utiliser les options convertErrorsToExceptions, convertNoticesToExceptions et convertWarningsToExceptions qui convertissent les messages respectifs en exception que l’on peut intercepter, puis d’utiliser les annotations @expectedException ou les méthodes setExpectedException (‘ExceptionName’);

Cette méthode présente malheureusement l’inconvénient de stopper l’exécution du script et empêche donc le test du code placé après la dite exception (et j’aime pouvoir disposer pour certaines bibliothèques d’une couverture de code au plus proche des 100%).

Exemple de code qui ne pourrait être testé avec la conversion notice=>exceptions

foreach ($classesInFileName as $className){
	if (isset ($allClasses[$className]) 
             && is_array ($allClasses[$className])){
		if (in_array($fileName, $allClasses[$className], true)){
			trigger_error("The class $className was found twice", E_USER_WARNING);
//Tout le code qui suit ne peut être testé, ce qui est regrettable car l'erreur n'est pas "bloquante"

Une solution avec les Mock Objects

Une solution réside simplement dans l’utilisation des Mock Objects que l’on va enregistrer comme gestionnaires d’erreurs.

Voici un exemple

//Création de l'objet fictif avec une méthode error_handler
$errorH = $this->getMock ('ErrorHandler', array ('error_handler'));
//On indique que la méthode error_handler doit être appelée au moins une fois.
$errorH->expects ($this->atLeastOnce())->method ('error_handler');
//Notre objet fictif est maintenant enregistré comme gestionnaire d'erreurs le temps du test
set_error_handler (array($errorH, 'error_handler'));

//---On peut maintenant tester le code qui génère une NOTICE / WARNING / ERROR

//On restaure l'ancien gestionnaire d'erreurs
restore_error_handler ();

Cette méthode n’est peut être pas conventionnelle, mais elle à le mérite de correspondre à mes besoins.

Et vous, comment testez vous ce genre d’erreurs ?

7 réflexions sur « PHPUnit – Tester les Erreurs, Warnings et Notices »

  1. Ping : Tweets that mention PHPUnit – Tester les Erreurs, Warnings et Notices | Gerald's Blog -- Topsy.com

  2. Atoum…… Je suis en train de développer un projet (tout neuf, PHP 5,3+ only). Pour le moment j’ai testé mes quelques classes avec PHPUnit, mais je ne serais pas contre profiter de l’occasion pour m’essayer à une autre solution de tests unitaires.

    Question bête à laquelle je ne suis pas arrivé à répondre : par ou je commence ? (y’a une doc ? un comparatif des possibilités avec PHPUnit ? Quels sont les avantages vis à vis de PHPUnit ?)

    • Atoum est encore en développement.
      La documentation est donc pour le moment absolument inexistante, mais la prise en main de l’outil est vraiment très simple, de l’avis de ceux qui l’utilise déjà.
      Je t’invite donc à regarder les classes de tests d’Atoum (puisque évidemment il s’auto-test) pour comprendre sa philosophie de fonctionnement (mais en gros, il y a un fichier à inclure dans ta classe de test, et c’est tout).
      Tu peux également te rendre sur le canal IRC ##atoum sur Freenode, tu y trouvera toute l’assistance dont tu peux avoir besoin.
      En ce qui concerne les différences entre PHPUnit (et SimpleTest), elles sont très nombreuses, mais je ne veux pas me lancer dans la comparaison, car je pense que ce n’est pas à moi de la faire, mais aux utilisateurs, vu qu’en tant que concepteur d’Atoum, je ne suis pas forcément le plus objectif (pour être honnête,j’ai développé Atoum parce que les autres solutions me sortait par les yeux).
      Je peux cependant te dire que l’API d’Atoum est complètement différente, notamment au niveau des assertions et des mocks, et il fait de plus de l’isolation de test nativement par défaut (c’est à dire que chaque méthode de test est exécutée dans un processus PHP différent).
      De plus, comme il utilise à plein les possibilités offertes par PHP >= à 5.3, son architecture est bien plus moderne et modulaire.
      Il est également plus rapide et efficace en terme de performance.
      Tout cela est induit entre autre par le fait que l’objectif d’Atoum est de faciliter la mise en œuvre et l’écriture des tests unitaires par rapport aux autres frameworks de tests unitaires.
      Enfin, Atoum étant développé en méthode agile, seul l’indispensable permettant de répondre à un besoin réel est développé.
      Il se peut donc qu’il ne réponde pas à tous tes besoins (même si à l’usage, il couvre les besoins courants).
      Dans ce cas, je t’invite à me faire remonter l’information et le nécessaire sera fait dans les meilleurs délais.
      Bienvenue dans l’aventure, si elle te tente toujours !

  3. Petite précision, que tu peux rajouter à mon commentaire précédent si tu le désire, une fois ta classe de tests écrites dans par exemple path/to/file, un simple php path/to/test/file te permet de lancer l’exécution de tes tests.
    Il est également possible de passer par le runner path/to/atoum/scripts/runner.php via php path/to/atoum/scripts/runner.php -t path/to/test/file.
    Il dispose de plus d’options supplémentaires que je t’invite à découvrir via php path/to/atoum/scripts/runner.php -h.

  4. Ping : Testez votre code avec Atoum | Gerald's Blog

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *