Si vous êtes développeur, je pense que vous avez surement entendu parler des tests unitaires (unit test) et j’espère que vous êtes convaincu de leur utilité ! Tester unitairement un morceau de code, c’est vérifier que celui-ci fait ce que l’on souhaite dans de multiples situations. Ensuite, on peut passer sereinement aux tests d’intégration qui vont tester plusieurs morceaux de codes (ou d’applications) entre eux. On peut encore raffiner avec des tests de performances, tests système, etc, etc… Tout dépend jusqu’où on souhaite aller.
Si on est capable de lancer régulièrement l’exécution de nos tests unitaires, alors on est capable de dire que notre code continue de fonctionner comme voulu malgré les mises à jours ou les refactoring. Cela n’empêche pas les erreurs ni les bugs, car on ne peut pas tester tout notre code unitairement, ou cela peut lamentablement planter lors de l’intégration. Néanmoins, on sait qu’une base solide « fonctionne comme prévu », ce qui facilite grandement la correction d’une erreur.
Pour des myriades de raisons :
tester son code c’est génial !!!
Des études prouvent même qu’une bonne gestion des tests permet au final de gagner du temps. Si vous n’y croyez pas, je vous invite sérieusement à reconsidérer votre opinion.
Ce que j’ai déjà vu dans certains environnements et ce que j’aimerai reproduire dans mon environnement Qt / C++, se résume ainsi :
- Créer facilement des tests cases : c’est-à-dire des tests unitaires sur une classe donnée
- Exécuter une test suite : c’est-à-dire lancer à la suite tous les tests cases d’un projet
- Afficher joliment les résultats d’une test suite
- Calculer le code coverage : c’est-à-dire la couverture de test d’un projet, ça motive à en écrire d’autres 😉
- Compiler le code et exécuter régulièrement des tests suites : pour faire de l’intégration continue, avec Jenkins par exemple
- Éventuellement : pouvoir créer facilement des Mocks, c’est-à-dire simuler un objet A pour tester un autre objet B qui dépend de A
- Éventuellement : tester aussi l’IHM de manière automatique
- Idem avec des integration tests automatisés
Résultats de tests dans Jenkins
C’est possible dans d’autres environnements :
- En PHP, on utilisera PHPUnit ou le tout nouveau atoum. On peut ensuite laisser Jenkins ou PHPCI gérer l’intégration continue. Tout un tas d’outils pourront aussi nous calculer facilement le code coverage, le niveau de qualité du code,lister des erreurs à éviter, … On peut aussi laisser un service Web comme Travis ou Scrutinizer gérer ce détails. Ils s’interfacent magnifiquement avec Github et Packagist, c’est une vraie merveille !
- En Java, l’inévitable JUnit parfaitement intégré dans Eclipse, Maven, Jenkins, … Le code coverage peut se calculer à l’aide de Cobertura ou Emma. Le mock se fait merveilleusement avec Mockito.
En Qt / C++, la vie est moins rose… On peut utiliser par exemple Google Test, et son compadre Google Mock pour tester du code C++. Une autre solution est de se servir de la bibliothèque QTestLib qui permet de tester directement du code Qt.
Ensuite pour le calcul de la couverture des tests, on a Gcov et il nous faut des outils pour afficher joliment ce résultat : Gcovr (traduit ce résultat en quelque chose au format de Cobertura pour une intégration dans Jenkins) ou bien Lcov (traduit ce résultat en HTML).
Mais le fait est :
Créer une architecture de tests en Qt / C++ n’est pas une sinécure !
C’est sur QTestLib que j’aimerai m’appesantir en quelques articles. Car J’arrive à lancer régulièrement une suite de tests et afficher le résultat dans Jenkins. Je commence à pouvoir gérer proprement le code coverage et l’analyse des bonnes pratiques. Mais les tests d’intégration automatiques ou bien les mocks, on y est pas encore. J’aimerai détailler mon architecture actuelle, créée à partir de bribes pêchées ici ou là sur le Web, dans l’espoir que cela puisse servir un jour !
A noter : il existe une différence entre QtTestLib et QTestLib ! Le premier étant à oublier aux oubliettes : il n’est plus supporté. Le second étant ce que je présente dans cet article.
