Dans un de nos projets Zend Framework 2, nous utilisons plusieurs modules : La gestion d’utilisateur, de contenu, etc. Nous souhaitions sous Jenkins refuser le build lorsque la couverture de code n’atteint pas une certaine valeur par module. L’outil le permettant n’existait pas… Nous l’avons créé : L’excellent Marco Pivetta a concocté coverage-checker, qui sera notre base de travail. Seul hic, il ne prend en charge qu’un seul module. Voici ci-dessous le fonctionnement de notre version de coverage-checker et son implémentation. Enjoy !

Rappel du fonctionnement de coverage-checker ?

Dans le build de jenkins, nous appelons le coverage checker qui prendra deux paramètres :

• le module qui doit être testé
• le taux de couverture minimum

Si le taux de couverture minimum est supérieur au taux de couverture réalisé par les tests (dans le cas où il n’y a pas assez de tests), alors il enverra un message d’erreur à Jenkins. Nous avons décidé que cela arrêtera le build Jenkins et donc le déploiement sur notre serveur d’intégration.

Si le taux de couverture minimum est inférieur au taux de couverture réalisé par les tests (dans le cas où tout est bien testé), alors il enverra un message de succès à Jenkins.

Voici le fonctionnement par défaut du coverage checker.

Modification du coverage checker

Nous avons donc dû prendre en compte la notion du multi-module. Ainsi, nous avons créé un fichier xml qui décrit l’ensemble des modules et la limite à atteindre pour la couverture des tests de chaque module.

<?xml version="1.0" encoding="UTF-8"?>
  <project>
    <modules>
      <module>
        <name>user</name>
        <path>vendor/adfab/user</path>
        <limit>10</limit>
      </module>
...

En plus de cela, nous avons ajouté des fonctionnalités complémentaires :

• une vue en HTML d’un tableau récapitulent les différents modules avec leurs taux de couverture et leurs limites.

• une vue dans la console avec les différents modules et leurs taux de couvertures.

Utilisation

La partie HTML va être utilisée par Jenkins. Le rapport est en effet sauvegardé au format HTML dans le même répertoire que coverage-checker. Dans le job Jenkins, il suffira alors d’ajouter un nouveau rapport html avec la config suivante :

Quant aux développeurs, ils pouront bénéficier du même rapport en ligne de commande et afficher le pourcentage de couverture après leurs tests : Le rêve !

Nous avons pour notre part utilisé une config Ant afin de permettre de lancer l’intégralité des tests unitaires de chacun des modules puis d’enchainer sur le coverage-checker.

<target name="coverage-checker" depends="phpunit">
    <exec dir="/usr/bin" executable="php" failonerror="true" description="check unit test coverage percentage">
	<arg line="${basedir}/build/coverage-checker.php" />
    </exec>
</target>

Conclusion

Grâce à cette fonctionnalité, nous pouvons désormais stopper un build si le niveau de tests unitaires n’est pas (plus) suffisant.

Et comme toujours, parce que vous le valez bien, nous vous mettons à disposition coverage-checker en multi-modules : https://github.com/AdFabConnect/coverage-checker