Il y a approximativement 2 ans, nous avons commencé à ajouter quelques tests unitaires dans le projet GLPI ; grâce à Valentin et Remi Collet. Le framework PHPUnit avait été retenu, puisqu’il s’agit du choix le plus “commun” pour un projet PHP.
Malheureusement, de nombreuses parties du code ne sont pas encore testées… C’est une très grosse tâche ; mais nous y travaillons. Actuellement, toute nouvelle fonctionnalité implémentée dans GLPI est pourvue de tests unitaires ; et nous prévoyons de passer du temps cet été pour travailler sur tout cela.
Pourquoi maintenant ?
J’apprécie personnellement atoum depuis ses tout débuts, j’ai proposé la migration il y a un certain temps. Puisque nous prévoyons l’ajout de plus en plus de tests ; la migration était plus facile tant qu’il y en a encore relativement peu. Voilà pourquoi ça a été fait maintenant.
Donc, pourquoi migrer ?
Et bien… S’agissant de framework de tests unitaires en PHP, il n’y a pas tant de choix possibles. PHPUnit est probablement le plus ancien framework de tests unitaires disponible en PHP ; et il fait son travail, pas de problèmes. atoum représente une choix plus récent et moderne, il possède aussi quelques possibilités fort intéressantes :
- test des types de variables (si vous testez un entier et obtenez une chaîne de caractères, ce n’est pas correct),
- merveilleux système de bouchonnage (qui permet de bouchonner les fonctions natives de PHP, des constantes, …),
- utilisation de fonctions anonymes pour tester les sorties, les exceptions, … (bien plus intéressant que les annotations de phpunit),
- lancement concurrent des tests (bien que ceci ait été désactivé pour GLPI),
- tests entièrement isolés,
- appels chaînés,
- écriture des tests davantage naturelle (il ne s’agit peut être que de mon point de vue – mais ça me semble vraiment plus simple).
De plus, GLPI est un projet français, la plupart des membres du cœur sont français, tout comme atoum ! 😉
Sur une note technique
Passer de PHPUnit à atoum n’est pas quelque chose de très complexe, surtout si vous n’avez pas utilisé de fonctionnalités très avancées (ce qui est le cas pour GLPI) ; mais cela ne peut pas vraiment être automatisé. En fait, si, ce serait possible pour certains cas communs, mais revoir les tests n’est globalement pas plus mal. Aussi, ré-écrire les tests est un excellent point de départ pour apprendre la nouvelle syntaxe, les assertions et les possibilités offertes.
Pour le projet GLPI, nous avons passé deux jours à travailler sur cette réécriture. Voici ce à quoi nous avons du prêter attention :
- atoum n’est pas du tout permissif. Toute notice dans le code fait échouer les tests par défaut (ce qui est une bonne chose) ; nous avons du les corriger ;
- nous réalisons plutôt des tests fonctionnels et pas seulement unitaires. Certains tests existants modifiaient les valeurs existant en base avant de les réinitialiser. Ce n’est pas possible lorsque les tests sont lancés de manière concurrente ;
- atoum ne permet pas de rendre des tests dépendants d’autres tests ; ce que permet phpunit. Cela pourrait ressembler à un point négatif, mais “les tests sont isolés”. Donc… Ils ne peuvent être inter-dépendants, nous avons du trouver d’autres solutions ;
- utilisation des sessions : GLPI utilise de nombreuses données stockées en session ; et cela pose un réel problème pour les tests… Nous avons du désactiver la concurrence des tests à cause de ça :’(
Le futur
Dans un futur proche, nous prévoyons d’améliorer nos tests unitaires ; puisque de nombreuses parties du code ne sont pas testées du tout. Nous prévoyons aussi de scinder notre dossier unique en plusieurs, rendant ainsi possible de ne désactiver la concurrence uniquement sur les tests fonctionnels et pas sur la suite entière.
Johan Cwiklinski.