Avec Jelix et Etna, j'ai maintenant pris l'habitude de développer des tests unitaires pour les choses compliquées, et un parser wiki est quelque chose qui est suffisamment compliquée pour avoir des chances d'avoir des bugs de régression à chaque modification du code. La succession des versions 2.0.x de wikirenderer en est la preuve :-). Je ne veux plus avoir à faire à la même situation. L'utilisation de tests unitaires est donc primordiale. Donc acte avec simpletest.

J'aime bien simpletest. C'est une bibliothèque autonome, bien foutue et suffisamment complète.

Il y a cependant un petit truc qui m'ennuie, c'est lorsque que l'on veut vérifier qu'un objet possède bien les bonnes valeurs dans toutes ses propriétés, et vérifier que les méthodes renvoient bien ce qu'il faut. Pour les gros objets, cela devient fastidieux. Et quand il faut le vérifier sur plusieurs dizaines de tests, cela m'est devenu vite pénible (par exemple tester le contenu d'un objet renvoyé par une méthode que l'on appelle des dizaines de fois avec des paramètres différents).

J'ai alors créer une nouvelle classe pour simpletest, avec deux nouvelles méthodes : assertComplexIdenticalStr et assertComplexIdentical. Elles prennent en argument un objet à tester, et un contenu XML (soit dans une chaîne, soit stocké dans un fichier), qui décrit le contenu de l'objet.

Un exemple (bidon) :

<object class="jDaoMethod">
   <string property="name" value="foo" />
   <integer property="type" value="3" />
   <boolean property="distinct" value="false" />
   <object method="getConditions()" class="jDaoConditions">
       <array property="order">array('foo','bar')</array>
       <array property="fields">
            <string key="foo" value="bar" />
      </array>
       <object property="condition" class="jDaoCondition">
           <null property="parent"/>
           <array property="conditions"> array(...)</array>
       </object>
   </object>
</object>

Le schéma de ce contenu xml est simple. Les balises représentent un type de donnée. Quand elles sont filles d'une balise object, elles doivent avoir un attribut property ou method indiquant la propriété et la méthode que l'on veut tester. Quand elles sont filles d'une balise array, elles peuvent avoir une propriété facultative key indiquant la clé de la valeur que l'on veut tester (vous remarquerez aussi que pour tester un tableau, on peut indiquer son équivalent php, pour les tests "simples"). Suivant les balises, on a aussi des attributs value, class, qui indiquent respectivement la valeur attendue et le type de classe.

Bref, j'aime bien cet aspect déclaratif. Ce n'est pas plus long à écrire que des lignes de codes "simpletest", bien au contraire. Par exemple, en écrivant simplement ceci <string property="name" value="foo" />, cela effectue trois tests unitaires : la présence de la propriété, son type, et sa valeur (ce qui représente au moins 3 lignes de code en php avec simpletest, voir plus selon le type de valeur).

Si vous voulez récupérer cette classe, c'est dans le dépot de jelix. Elle le sera bientôt dans celui de wikirenderer ;-)

Autre chose, j'utilise aussi dans les tests de wikirenderer, la bibliothèque diff de phpwiki, pour afficher les différences quand le test entre deux chaînes est négatif. Trés utiles quand lesdites chaînes comportent des textes entiers. Pour l'occasion, j'ai du faire un nouvel objet de formatage diff, car celui donné par phpwiki utilisait une lib interne à phpwiki pour générer le html, ce que je ne voulais pas (trop de dépendance à gérer, trop lourd..). C'est actuellement dans le dépôt de wikirenderer, et je le migrerais très certainement dans celui de Jelix.

Quand deux projets se nourrissent mutuellement ... :-)