Chapter 6. Tests automatisés

6.1. Introduction
6.2. Automatisez vos tests unitaires et d'intégration
6.3. Configuration des rapports de test dans Jenkins
6.4. Afficher les résultats de test
6.5. Ignorer des tests
6.6. Couverture de code
6.6.1. Mesurer la couverture de code avec Cobertura
6.6.1.1. Intégrer Cobertura avec Maven
6.6.1.2. Intégrer Cobertura avec Ant
6.6.1.3. Installer le plugin de couverture de code Cobertura
6.6.1.4. Les rapports de couverture de code dans votre build
6.6.1.5. Interpréter les métriques de couverture de code
6.6.2. Mesurer la couverture de code avec Clover
6.7. Tests d'acceptation automatisés
6.8. Tests de performance automatisés avec JMeter
6.9. A l'aide ! Mes tests sont trop lents !
6.9.1. Ajouter plus de matériel
6.9.2. Lancer moins de tests d'intégration/fonctionnels
6.9.3. Exécutez vos tests en parallèle
6.10. Conclusion

6.1. Introduction

Si vous n'utilisez pas les tests automatisés avec votre environnement d'intégration continue, vous passez à côté d'un aspect important. Croyez-moi — l'IC sans les tests automatisés représente juste une petite amélioration pour les tâches de build lancées automatiquement. Maintenant, ne vous méprenez pas, si vous partez de zéro, c'est quand même un grand pas en avant, mais vous pouvez faire mieux. En résumé, si vous utilisez Jenkins sans tests automatisés, vous n'obtenez pas autant de valeur de votre infrastructure d'intégration continue que vous le devriez.

Un des principes de base de l'intégration continue est qu'un build doit être vérifiable. Vous devez être capable de déterminer objectivement si un build donné est prêt à passer à la prochaine étape du processus de construction, et le meilleur moyen de le faire est d'utiliser les tests automatisés. Sans une bonne automatisation des tests, vous allez devoir conserver de nombreux artefacts construits et les tester manuellement, ce qui est contraire à l'esprit de l'intégration continue.

Il y a plusieurs façons d'intégrer les tests automatisés dans votre application. Une des façons les plus efficaces pour écrire des tests de haute qualité est de les écrire en premier, en utilisant des techniques comme Test-Driven Development (TDD) ou Behavior-Driven Development (BDD). Dans cette approche, utilisée couramment dans de nombreux projets agiles, le but de vos tests unitaires est à la fois de clarifier votre compréhension du comportement du code et d'écrire un test automatisé prouvant que le code implémente le comportement. En se concentrant sur le test du comportement attendu de votre code, plutôt que sur son implémentation, cela rend les tests plus compréhensibles et plus pertinents, et par conséquent aide Jenkins à fournir une information plus pertinente.

Bien entendu, l'approche plus classique mettant en oeuvre des tests unitaires, quand le code a été implémenté, est aussi couramment utilisée, et est certainement mieux que pas de tests du tout.

Jenkins n'est pas limité aux tests unitaires, cependant. Il y a plusieurs autres types de tests automatisés que vous devriez envisager, selon la nature de votre application, parmi les tests d'intégration, les tests web, les tests fonctionnels, les tests de performance, les tests de charge et autres. Tous ceux-ci ont leur place dans un environnement de build automatisé.

Jenkins peut aussi être utilisé, en conjonction avec des techniques telles que Behavior-Driven Development et Acceptance Test Driven Development, comme un outil de communication destiné à la fois aux développeurs et aux autres intervenants d'un projet. Des frameworks BDD tels que easyb, fitnesse, jbehave, rspec, Cucumber, et beaucoup d'autres, essaient de présenter les tests d'acceptation de sorte que les testeurs, les Product Owners, et les utilisateurs puissent les comprendre. Avec de tels outils, Jenkins peut fournir des informations sur l'avancement d'un projet en termes métiers, et ainsi faciliter la communication entre développeurs et les non-développeurs à l'intérieur d'une équipe.

Pour des applications existantes avec peu ou pas de tests automatisés existants, cela peut être difficile et consommateur en temps de mettre en place des tests unitaires complets dans le code. De plus, les tests peuvent ne pas être très efficaces, parce qu'ils auront tendance à valider l'implémentation existante plutôt que vérifier le fonctionnel attendu. Une approche intéressante dans ces situations est d'écrire des tests fonctionnels automatisés (“régression”) qui simulent les manières les plus courantes d'utilisation de l'application. Par exemple, les outils de tests web automatisés tels que Selenium et WebDriver peuvent être utilisés efficacement pour tester les applications web à un haut niveau. Alors que cette approche n'est pas aussi complète que la combinaison de tests unitaires, d'intégration et d'acceptation de bonne qualité, c'est quand même une façon efficace et économique d'intégrer des tests de régression automatisés dans une application existante.

Dans ce chapitre, nous allons voir comment Jenkins vous aide à conserver les traces des résultats des tests automatisés, et comment vous pouvez utiliser cette information pour surveiller et disséquer votre processus de build.