Utiliser consciencieusement les tests d'intégration - une étude de cas

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher

Auteur : J.B. Rainsberger
Source : Using integration tests mindfully: a case study
Date : 2010


Traducteur : Fabrice Aimetti
Date : 27/09/2011


Traduction :

Gus Power a laissé un commentaire sur la manière dont il utilise les tests d'intégration dans le cadre de son travail.

Gus-Power.png
Intéressante série d'articles et de commentaires. J'ai aussi lu l'article de Steve Freeman en réponse à ce sujet. Cela m'a fait réfléchir sur la façon dont nous travaillons et j'ai donc pensé prendre un peu de temps pour le décrire ici.

Vous définissez un test d'intégration comme "... un test dont le résultat (réussite ou échec) dépend de la mise en oeuvre correcte de plus d'un comportement significatif du système". Nous avons de nombreux composants qui présentent de tels comportements non triviaux au sein des produits que nous créons, et beaucoup ne sont pas développés par nous. Et nous avons des tests d'intégration pour vérifier leur fonctionnement. Ici, je ne parle pas seulement de librairies tierces et de frameworks, je me réfère à l'ensemble du système : la mise en cache, la répartition de charge, les serveurs DNS, les réseaux de distribution de contenu (CDN), la virtualisation, etc. Quand nous construisons un logiciel, il ne devient uniquement un produit ou un service pour nos utilisateurs que quand il a été déployé dans un environnement intégré ; un environnement qui contient généralement plus que le logiciel que nous avons écrit et packagé. Puisque l'expérience de nos utilisateurs et leur perception de la qualité résulte de leur interaction avec une instance déployée de l'ensemble du système, et non pas seulement de leur interaction avec le logiciel en tant que tel, nous en sommes arrivés à valoriser des tests d'intégration de bout en bout. Je crois qu'il y a du mérite à tester des composants qui communiquent je vais tenter de clarifier le type de tests d'intégration dont je parle.
Pour un fragment donné de fonctionnalité, nous écrivons un test d'acceptation exécutable sous forme lisible par un humain (pour les projets web, nous utilisons généralement certains extensions de domaines spécifiques à sélénium, pour les services nous avons utilisé FIT et autres outils du même acabit, et parfois nous utilisons nos propres outils si rien de disponible ne fait l'affaire). Nous les exécutons sur une version déployée de l'application (généralement en local mais pas toujours) qui a généralement un serveur web/applicatif et une base de données opérationnels. Le test échoue. Nous déterminons quel composant doit être créé/amélioré et nous revenons ensuite sur des tests unitaires. Un scénario typique impliquerait l'amélioration d'un test unitaire pour les mappings url, en en ajoutant un pour le contrôleur, puis un autre pour chaque nouveau service, objet de domaine, etc. Lorsque nous sommes satisfaits et que nous avons testé et conçu chacune des parties requises, nous retournons au niveau tests d'acceptation pour les faire progresser. Le client dirige l'effort de développement au fur et à mesure qu'il voit des "tranches" verticales de fonctionnalité émerger. Le test d'acceptation est ajouté à une suite de tests sur le domaine fonctionnel concerné. Le système d'intégration continue va ensuite exécuter ce test sur un environnement similaire à la production (mais moins bien dimensionné), avec un serveur physique de répartition de charge, des VLAN, plusieurs nœuds (affinité de session) et ainsi de suite. Toute surveillance supplémentaire de l'environnement (par exemple, un système d'alerte Nagios) est également faite dans le cadre de cet effort de développement et est déployée dans l'environnement de test avec le code mis à jour.
La mise en place de l'infrastructure nécessaire pour faire ce genre de test représente un sacré investissement, au début et tout du long. Le build continu doit être hautement "parallélisé" afin de pouvoir obtenir un retour en moins de 10 minutes suite à check-in (nous sommes de gros utilisateurs de la virtualisation, généralement avec VMWare ou OpenVZ). Les suites de tests d'acceptation doivent être conservées suffisamment petites pour s'exécuter rapidement avant le check-in.
Les avantages de cette approche :
  • Le basculement continu entre les tests d'acceptation et les tests unitaires est la clé pour rester concentré sur le fait de livrer ce que le client veut réellement.
  • Le client a de nombreuses opportunités de feedback à partir desquelles il peut apprendre des choses et les utiliser pour orienter l'effort de développement.
  • Cela confirme que le système entier fonctionne - le réseau, le DNS, la répartition de charges, le déploiement automatique, la gestion des sessions, la réplication des bases de données, etc.
  • Nous créons des tests d'acceptation "non-fonctionnels" en plus qui contrôle automatiquement d'autres aspects du système tels que les bascules et les reprises.
  • Les mises à jour de certaines parties du système (les commutateurs, les répartiteurs de charge, les caches web, les versions des librairies, les versions des serveurs de bases de données, etc.) peuvent être testées d'une manière maîtrisée.


Grâce à cette approche, nous avons traité un certain nombre de problèmes liés à l'intégration (quelques exemples : basculement suite à base de données corrompue à cause de clés primaires manquantes, la validation captcha qui ne fonctionne pas en raison d'un cache web qui ne se comporte pas correctement, données non persistantes parce qu'on n'a pas spécifié la bonne instance locale du serveur de base de données) et nous avons réussi à stopper ces problèmes avant d'impacter les utilisateurs.
Nous avons utilisé le feedback comme une base d'amélioration de nos produits et leur mode de livraison à un niveau système.
Bon, cette réponse est devenue beaucoup trop longue :-/ Il serait bien sûr intéressant d'en discuter en face à face à l'occasion.
Gus Power
Merci pour ce commentaire important, Gus. Pour ceux qui ne connaissent pas Gus, il est l'un des co-lauréats 2009 du prix Gordon Pask pour sa contribution à la pratique Agile. Je vous invite à suivre son travail et à apprendre sur son exemple.
Maintenant, sur le fond du commentaire de Gus :
Gus, il semble que vous n'utilisiez pas les tests d'intégration pour vérifier exhaustivement le comportement de base du système. Même si j'essaie de ne pas du tout utiliser les tests d'intégration pour vérifier le comportement de base, j'ai surtout l'espoir que les programmeurs arrêtent d'essayer d'écrire des tests d'intégration exhaustifs pour vérifier les conditions d'une conformité de base. J'ai écrit un billet Les tests d'intégration ne sont pas seulement lents, ils sont un tourbillon mortel sur le cercle vicieux que je vois quand les équipes s'appuient sur des tests d'intégration pour vérifier la conformité de base. Je les encourage en particulier à arrêter cette folie.
J'hésiterais à utiliser des tests d'intégration, même des tests fumigatoires[1] pour la conformité de base, mais si je devais me retrouver dans une situation où j'ai besoin d'écrire de tels tests, je le ferais, puis je chercherais des moyens de les rendre obsolètes.
Vous écrivez également "tests d'acceptation lisibles par un humain", et j'ai utilisé de tels tests dans mon travail. Lorsque je conseille de ne pas utiliser les tests d'intégration, je le conseille uniquement dans le cadre de tests bâtis par les développeurs. Même si j'encourage vivement les équipes à construire des tests d'acceptation pour vérifier le comportement de règles métiers, directement et de façon isolée, je comprends et j'accepte que l'on ait généralement besoin d'écrire quelques tests d'acceptation sous forme de tests d'intégration.
De façon générale, vous décrivez une utilisation des tests d'intégration tout à fait délibérée, consciencieuse et responsable. Je n'en attends pas moins d'un pratiquant de votre calibre. J'aurais vraiment du plaisir à travailler avec vous sur un projet.
Enfin, vous mentionnez que vos tests d'intégration détectent des problèmes au niveau du système, comme un schéma de base de données corrompu, des problèmes de cache, et ainsi de suite. Je m'attends à ce que les tests d'intégration détectent uniquement, ou au moins la plupart du temps, ces problèmes. Aucun de ces problèmes ne semblent concerner la conformité de base.
Ainsi Gus, j'apprécie que vous nous ayez donné une description approfondie de la bonne utilisation des tests d'intégration chez vous. Je souhaite que nous ayons plus d'exemples de ce genre. Je souhaite vraiment voir plus d'exemples de ce genre. Malheureusement, ce n'est pas le cas : je vois les équipes tentaient de vérifier les questions de conformité de base avec des tests laborieux, fragiles et trompeurs. Pour ceux-là, j'insiste sur la nécessité d'éliminer les tests d'intégration.


  1. Smoke tests