Project

General

Profile

Organisation des tests

J'ai pas mal tatonné avant de trouver une organisation des tests statisfaisante. Comme il n'y a pas d'équipe de testeurs sur le projet, il faut que les tests de validation soient automatisés. Sinon au fur et à mesure de l'augmentation de la taille du programme on va passer de plus en plus de temps a vérifier que les petites modifications n'ont rien cassé.

Philosophie

Il faut que les tests soient:

comme le spécifie la doc de PHPunit

  • Faciles à écrire
  • Faciles à comprendre
  • Faciles a lancer
  • Rapides
  • Indépendants
  • Composables
Dans notre cas il faut également:
  • Qu'ils permettent de tester les controleurs, modèles et objets des librairies CodeIgniter
  • Qu'il soient intégrés avec Jenkins
  • Debugable
  • Que la couverture soit mesurable

Initialement j'avais commencè à organiser tous les tests à l'aide de Selenium et donc à tester les objets CodeIgniter de façon indirecte.
C'est facile à écrire, il suffit d'enregistrer une session selenium et de l'exporter sous forme de test PHPUnit.

Je suis arrivé à une suite de tests assez difficile à maintenir.

La difficulté avec PHP et qu'on utilise tout un tas d'outil indépendant et qu'on veut les faire fonctionner
ensemble. Et que par opposition avec les environnements Java, tout n'arrive pas clé en main.
  • PHP
  • phpunit
  • eclipse
  • xdebug
  • CodeIgniter
  • Selenium

Les tests unitaires

J'ai abandonné CIUnit: [[http://d.hatena.ne.jp/Kenji_s/20120117/1326763908]] trop lourd pour le service rendu. J'utilise la classe Unit Testing de CodeIgniter. Elle a l'avantage d'être parfaitement intégrée. Avec elle on a aucun problèmes pour accéder à un contrôleur, ou un modèle, il suffit de faire comme si on était dans l'application.

Il y a un contrôleur test qui est spécialement en charge d'activer les tests de helpers et de librairies. Chaque contrôleur inclut également une méthode test en charge des tests de ses méthodes ainsi que du modèle associé.

L'ensemble de ses tests sont accessibles à travers l'écran d'administration.

Les tests Selenium Watir

Les tests Selenium étaient générés à partir d'enregistrement de sessions Firefox avec l'outil Selenium IDE. Comme Selenium, Watir est un environnent qui permet de piloter un navigateur (Firefox) pour rejouer des sessions de test. La différence est que Watir est une bibliothèque Ruby qui permet de structurer les tests beaucoup plus facilement. Avec Selenium, c'était trivial d'enregistrer un test, mais il fallait tout recommencer dés qu'un détail changeait. Avec Watir, c'est légèrement plus long de créer un test, mais ils sont beaucoup plus facile à faire évoluer en cas de besoin.

les tests activés par Jenkins

La mesure de couverture

La aussi j'ai beaucoup tâtonné avant d'arriver à quelque chose de satisfaisant. Etant donné l'intégration discutable entre PHPUnit et CodeIgniter, la mesure de couverture des tests n'était pas triviale. Je voulais pouvoir faire de la couverture incrémentale et connaitre la couverture de tous les types de tests. La aussi la solution à consisté à intégrer la mesure de couverture dans l'application elle-même. Une librairie "PersistentCoverage" permet d'activer la mesure de couverture. On utilise les "hook" CodeIgniter pour activer la mesure de couverture après la création de chaque contrôleur et on sauvegarde le contexte de couverture après chaque test. De cette façon, on peut récupérer les informations de couverture de chaque tests quelque soit sont type et son mode d'activation.

Sous Jenkins on présente la couverture globale.

Et le détail dans le code source est disponible directement en HTML par l'application dans ses écrans de maintenance.