Extr3mz pr0gr4mm1n

Donc, sur spip-zone on trouve désormais un répertoire tests/ , contenant une série de tests fonctionnels. L’objectif est d’avoir une batterie de vérifications automatiques, qui permettront de constater certains bugs avant qu’ils ne soient mis sur de « vrais » sites.

Commençons par l’installer (en local), à la racine de notre site SPIP ; en ligne de commande ça donne :

# cd Sites/spip/
# svn co svn://zone.spip.org/spip-zone/_core_/tests
# ls tests/

Une fois les tests installés dans le sous-répertoire tests/, on vérifie qu’on est bien connecté en tant qu’administrateur du site, et on dirige son navigateur vers l’url .../spip/tests/

C’est alors qu’apparaît un magnifique tableau de tests qui se chargent en asynchrone les uns après les autres. A la fin, si tout est vert, on a gagné. S’il y a du rouge c’est qu’il y a un test qui n’est pas passé.

À quoi ça sert ? Prenons le cas d’une fonction qui, ces derniers jours, nous a donné du fil à retordre. Il s’agit du filtre |extraire_attribut, qui prend en entrée un tag HTML (par exemple <img src='truc.gif'>) et le nom d’un attribut (par exemple src) ; le résultat doit être la chaîne "truc.gif".

Un test va valider le fait que ce filtre fonctionne bien pour ce cas-là ; si on modifie la fonction (pour l’accélérer ou pour lui faire faire des choses plus complètes), il suffira de faire tourner le jeu de tests pour vérifier qu’on n’a pas perdu en fonctionnalités.

Ce test consiste en un fichier, tests/filtres/extraire_attribut.php, qui comporte simplement les lignes nécessaires à valider le bon fonctionnement de notre fonction :

Au-dessus de ce test on aura inclus la librairie de tests et la fonction extraire_attribut par les lignes suivantes :

A la fin du test, on vérifie si on a une erreur, si oui on l’affiche ; s’il n’y a pas d’erreur on affiche simplement « OK » :

Voilà, c’est tout. Si vous ouvrez le fichier en question vous pouvez constater qu’on a mis plusieurs tests fonctionnels pour cette fonction, et qu’on n’affiche « OK » que si tous les tests ont validé. Sinon on affiche tous ceux qui ont échoué.

Tests de squelettes. Il est aussi possible de tester des squelettes. Pour cela il faut installer le squelette de test xxx.html dans un sous-répertoire du répertoire tests/, et faire en sorte que ce squelette affiche « OK » si tout se passe comme prévu.

Comme il est parfois difficile de faire un squelette qui produit exactement « OK », le système prévoit qu’on passe le résultat du squelette à travers une liste de filtres qu’on peut définir directement dans le squelette.

Ainsi par exemple le test xml/xmlhack.html indique qu’il faut filtrer son résultat à travers les fonctions trim() (supprimer les espaces) et strip_tags() (supprimer les balises html).

Le squelette xmlhack.html contient, au final, la séquence suivante :

À noter : on n’en est qu’au tout début, il est probable que les spécifications de tout ça vont évoluer. L’idée de base est que ces tests doivent être très simples à programmer, afin que chacun puisse fournir un maximum de tests fonctionnels.