L’intégration continue est une des treize pratiques de « l’extreme programming ». Elle vise à intégrer immédiatement les modifications du produit afin d’éviter la surcharge de travail liée à l’intégration de tous les éléments avant la livraison. Les tests facilitent grandement cette intégration : quand tous les tests passent, l’intégration est terminée.
Les outils d’intégration continue sont en fait assez simples (que ce soient Jenkins, Bamboo, ou TeamCity pour ne citer qu’eux). Il s’agit principalement d’un « ordonnanceur » qui se réveille lorsqu’un développeur « commit » du nouveau code dans le référentiel de contrôle de version (git, svn, …). Cet ordonnanceur lance des tâches visant à vérifier la qualité du nouveau « build ».
Il est très important de bien définir les tâches que doit réaliser la plateforme d’intégration continue, c’est de là que provient la qualité de votre intégration continue. En effet, votre « pipeline » d’intégration pourrait se contenter de juste compiler votre code. Mais dans ce cas il ne s’agit plus d’intégration continue, et votre « build » serait alors « vert » sans aucune information sur la qualité.
Les tâches de l’intégration continue devraient à minima contenir :
- La compilation et le « packaging » de l’application
- L’exécution des tests unitaires et la vérification de leur couverture
- Une analyse statique de la qualité du code (ou « test statique »)
Ceci n’est qu’un minimum, et ne permettra que de vérifier l’intégration logicielle, si vous voulez faire un pas vers le « continuous delivery », il faudra ajouter des tests fonctionnels et non fonctionnels automatiques. Un « pipeline » d’intégration continue devrait alors ressembler à cela :
Si la première partie est souvent (partiellement) présente, c’est rarement le cas pour les tests de plus haut niveau. Ils posent en effet des problèmes beaucoup plus complexes que de « simples » tests unitaires. Pour rappel, les tests unitaires (pour être de vrais tests unitaires) n’utilisent aucun environnement, embarquent leurs jeux de données, et de ce fait sont indépendants, peuvent être joués en parallèles et sont rapides à exécuter. Ce n’est généralement pas le cas des tests de plus haut niveau.
Les tests de plus haut niveau posent différents problèmes pour être automatisés et lancés en intégration continue :
- Ils demandent un environnement et des données qui ne sont pas toujours disponibles
- Ils sont souvent moins stables que les tests de bas niveaux, comme ils traversent toutes les couches de l’application, ils ont beaucoup plus de raisons d’échouer et de faire de faux positifs
- Ils sont plus lents à exécuter
En fait ces tests demandent une maturité en tests importante, et d’utiliser des pratiques et des outils adéquats avant d’être mis en place dans l’intégration continue :
- Virtualiser les environnements et les données et les créer à la demande. Des outils, comme Docker ou VMWare, permettent d’isoler les environnements virtuels, et les outils de virtualisation de services, comme WireMock par exemple, permettent de simuler les interfaces externes, et donc de bouchonner vos tests
- Eviter de lier trop fortement vos tests à votre interface utilisateur, c’est en effet la partie la moins stable, il faut donc soit baser les tests sur la couche API, soit utiliser des frameworks de tests qui ont une couche d’abstraction forte entre le test et l’IHM (comme Serenity BDD par exemple)
- Faire en sorte que tous les tests automatisés soient maintenus en même temps que le code permet d’assurer que ces tests sont vraiment maintenus. C’est en effet une bonne pratique de l’intégration continue : « qui casse le build, le répare ». C’est donc au développeur de mettre à jour tous les tests (et pas uniquement les tests unitaires) impactés par sa modification
- Faire de vos tests votre documentation vivante en la publiant et la mettant à disposition du métier à la fin du processus de build (sur un wiki par exemple)
- Mettre en place un autre principe de l’extreme programming : le build en moins de 10 minutes. Ceci signifie que les tests, même de bout en bout, doivent être « timeboxés ». Si leur exécution dépasse le délai imparti, il faut supprimer des tests !
Comme on le voit, l’intégration continue n’est pas juste une question de plateforme d’intégration continue, mais bien de process de build incluant des tests matures et maîtrisés.
Installer Jenkins (certainement la plateforme la plus populaire) n’est donc pas suffisant, il faut surtout revoir comment sont gérés les tests automatiques, et respecter les pratiques agiles comme la pyramide de tests.
La réussite dans un projet agile est avant tout une question de tests. L’intégration continue vous permettra de lancer régulièrement et sans même y penser ces tests, et d’assurer cette intégration, mais cela nécessite une bonne maitrise et l’utilisation d’outils adéquats.
4 réponses
J’apprécie que l’article montre que la qualité de l’intégration continue dépend en fait de la bonne mise en place des tests automatisés, et non pas seulement d’un outillage.
Toutefois, l’article ne fait pas le lien avec le Continuous Testing (cf. Le titre de l’article). Et le pipeline d’intégration continue omet les tests d’intégration et les tests non-fonctionnels.
Bonjour Xavier,
je ne suis pas l’auteur de l’article mais confirme que les tests non-fonctionnels ne font malheureusement pas parti de ce qui est présenté.
Lorsque l’on écrit on doit faire des choix pour ne pas s’éparpiller et ces notions en on fait les frais.
Je peux par contre t’indiquer que ces notions sont bien prises en comptes dans des articles qui sortiront prochainement dans la taverne!
Tout à fait, les tests non fonctionnels sont (trop) souvent oublié et malheureusement difficile à mettre en place dans l’intégration continue.
C’est possible, mais clairement difficile de faire des tests de charges ou des tests d’intrusion à chaque commit… Mais si vous avez des retours d’experience sur la mise en place de tests non fonctionnels dans une intégration continue, vous pouvez évidement la partager dans la taverne du testeur !
Bonjour à tous. Je tiens à vous remercier pour cet article très informatif, qui met en lumière l’importance de l’intégration continue dans le développement logiciel univirtual, en particulier dans un contexte agile. L’intégration continue ne se limite pas simplement à la mise en place d’outils comme Jenkins ou Bamboo ; elle repose sur un workflow bien défini et rigoureux qui inclut la gestion des tests automatiques à chaque étape du processus de développement. Cette méthodologie vise à intégrer les modifications de code fréquemment, tout en assurant la qualité grâce à des tests automatisés, tels que les tests unitaires, mais aussi des tests plus complexes de plus haut niveau. Dans le domaine du développement web univirtual, les tests jouent un rôle essentiel, car ils permettent de vérifier en continu que chaque nouveau code intégré respecte les exigences de qualité, sans introduire de régressions.