BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Articles Integration Testing from the Trenches, l'interview

Integration Testing from the Trenches, l'interview

Favoris

A l'occasion de la sortie en avant-première du livre Integration Testing from the Trenches (le test d'intégration depuis les tranchées), InfoQ FR a pu discuter avec son auteur, Nicolas Fränkel, des problématiques de tests d'intégration, et de comment les implémenter efficacement.

InfoQ FR : Bonjour Nicolas, tu es en cours d'écriture de ton nouveau livre 'Integration Testing from the Trenches', peux-tu nous le présenter ?

Nicolas Fränkel : Bonjour Pierre, 'Integration Testing from the Trenches' part d'un constat assez simple que je fais depuis quelque temps déjà. Les méthodes de tests unitaires sont aujourd'hui plutôt bien établies, mais étrangement la qualité intrinsèque des logiciels n'augmente pas en conséquence, car les architectures actuelles font de plus en plus appel à des ressources externes. Or, quand on veut vérifier le bon fonctionnement d'une voiture, on vérifie bien sûr la qualité de chacun des boulons pris individuellement mais on emmène également la voiture sur tapis roulant pour aller plus loin. Les tests d'intégration sont comme la vérification du fonctionnement de la voiture sur le tapis roulant.

Tests d'intégration et tests unitaires partagent certaines propriétés communes, mais il existe des différences fondamentales : les tests d'intégration sont par nature plus longs et plus fragiles. Pour en diminuer les conséquences, il existe toute une panoplie d'approches de méthodes et d'outils dédiés aux tests d'intégration. C'est l'approche que j'ai adoptée dans l'écriture de 'Integration Testing from the Trenches' : décrire comment aborder les tests d'intégration pour bénéficier d'un retour sur investissement maximum.

InfoQ FR : Toute politique de tests d'intégration doit être maintenue, qui selon toi est le mieux placé pour le faire ? Une équipe QA, ou plutôt une équipe de dev ?

Nicolas Fränkel : Les tests d'intégration sont étroitement dépendants de l'architecture logicielle. A ce titre, ils ne peuvent être développés et maintenus que par des développeurs.

InfoQ FR : Dirais-tu qu'aujourd'hui nous avons tous les outils nécessaires en open-source pour implémenter une couverture de tests d'intégration efficace ? Y'a-t-il des briques non encore disponibles qui amélioreraient encore l'ensemble ?

Nicolas Fränkel : Les ressources d'infrastructure les plus communes avec lesquelles il est nécessaire de s'intégrer sont les bases de données, les serveurs d'application, les web services REST et SOAP, les serveurs mails et les serveurs FTP. Pour chacune de ces briques, il existe des outils Open Source qui permettent de mettre en place des ressources Fake configurables dans le cadre d'un test. Le seul manque que j'ai pu identifier pour l'instant est l'absence de Fake sur les bases de données NoSQL (sauf MongoDB). Toutefois, au vu de la criticité de tester des systèmes utilisant de telles bases de données, ce n'est qu'une question de temps.

De manière générale, toute nouvelle technologie ou tout nouveau framework va rencontrer la même problématique. Les outils facilitant le test, le déploiement, etc... suivent de près ou de loin chaque nouveauté qui rencontre le succès.

InfoQ FR : David Heinemeier Hansson (DHH, le créateur de Rails) a récemment écrit un article un peu polémique sur la mort à ses yeux du TDD et l'entrée dans l'ère du test de système, plutôt que du test unitaire. Qu'en penses-tu ?

Nicolas Fränkel : Tout d'abord, je me permets de faire la distinction entre le TDD et la pratique du test unitaire. Je ne suis pas un farouche pratiquant du TDD, mais je n'imaginerais pas livrer du code sans ces tests unitaires associés. De plus, la réflexion de David est à mon sens circonscrite à Rails.

Toutefois, en reprenant l'image de la voiture, j'affirme qu'il existe une complémentarité entre les tests unitaires et les tests d'intégration. Il est bien sûr possible de tester le bon comportement d'une voiture sur circuit, mais si elle s'effondre au premier coup de volant par la faute d'un boulon de mauvaise qualité, quelle perte de temps ! De plus, si un échec survient, les causes potentielles sont virtuellement infinies ; alors que si chaque pièce a été testée au préalable, c'est bien l'assemblage qui devra tout d'abord être mis en cause.

Dans le cadre d'un logiciel, c'est exactement le même principe. De plus, au vu de l'investissement conséquent des tests d'intégration, je préconise même une structure pyramidale, avec les tests unitaires à la base et les tests d'intégration "au-dessus". Plus l'intégration enrôle un nombre élevé de ressources, moins le nombre de tests devrait être élevé.

InfoQ FR : L'arrivée des architectures de type micro-services, et notamment ceux de type REST, va-t-elle permettre de promouvoir encore plus le test d'intégration dans les années qui viennent ?

Nicolas Fränkel : J'irais même plus loin que la simple promotion. Plus les applications vont utiliser des ressources complexes et différentes, plus les tests d'intégration seront nécessaires ! Si votre application utilise des web services REST (et/ou SOAP), comment garantir qu'elle fonctionne de manière nominale uniquement en testant unitairement ? Il devient indispensable de tester les classes qui interagissent avec les frontières du système, et ce n'est possible qu'en mettant en place un service Fake.

InfoQ FR : Le test unitaire a fait pas mal évoluer le style de design architectural interne aux applications, notamment avec l'injection de dépendances, etc. Penses-tu que le test d'intégration va aussi faire évoluer notre capacité à designer des systèmes complexes ?

Nicolas Fränkel : Je ne crois pas. Les tests unitaires ont rendu nécessaire l'injection de dépendances, ce qui favorise la conception de petites classes à responsabilité unique. Mais le Principe de Responsabilité Unique faisait déjà partie des principes SOLID associés à la Programmation Orientée Objet. D'autre part, il est tout à fait possible de mal utiliser l'injection de dépendances : il m'arrive régulièrement d'observer des classes avec trop de dépendances, qui utilisent l'injection d'attributs, etc.

Il est absolument fondamental de décorréler le paradigme (p.e. la Conception Orientée Objet), la méthode de test (p.e. les Tests d'Intégration) et les outils. On peut parvenir à une application respectant les principes SOLID sans injection de dépendances, alors que sa seule utilisation ne conduit pas forcément à un code robuste et maintenable.

InfoQ FR : Quel regard portes-tu sur la mouvance BDD (Behavior Driven Development) ?

Nicolas Fränkel : A mon sens, le BDD est une excellente approche, car elle permet un meilleur alignement entre le métier et le code. Mais il s'agit d'adresser une problématique différente des tests d'intégration.

InfoQ FR : Dans ton livre à paraître, tu abordes par exemple les problématiques de Fakes, qui sont à leur détriment peu décrites comparées aux Mocks. Est-ce que tu peux nous en parler un peu ?

Nicolas Fränkel : Bien sûr. Martin Fowler a décrit l'intégralité de ce qu'il appelle des Tests Doubles, dont font partie les Fakes et les Mocks dans un article célèbre. Mais les Mocks comportent les limitations suivantes :

  • Si vous utilisez un Mock, vous allez devoir coder le comportement attendu. Plus la complexité du comportement d'un objet à mocker grandit, plus la maintenabilité du test qui l'utilise est importante. Par exemple, si dans un servlet j'interagis avec HttpSession, il est nécessaire de coder que l'appel à getHttpSession() renvoie un objet MockHttpSession, ainsi que le code des différentes méthodes utilisées de ce dernier.
  • De plus, certains comportements doivent être similaires dans tous les tests comme dans le cas précédent. Pourquoi alors re-coder ce comportement dans chaque test (ou chaque projet) ?
  • Finalement, l'utilisation de Mock n'a plus aucun sens lorsque l'objet à tester interagit avec des ressources hors des limites du système. Le cas d'utilisation le plus parlant est le Data Access Object. Si on veut le tester, que va-t-on mocker ?

Les limitations précédentes montrent bien qu'il est nécessaire de disposer d'un objet out-of-the-box qui a un comportement par défaut cohérent dans certains cas, notamment les API et les ressources externes. Ces objets sont des Fakes.

InfoQ FR : Un chapitre est consacré au test automatisé et son adoption via l'intégration continue - c'est un des sujets qui montent en ce moment dans les équipes dans lesquelles tu interviens ?

Nicolas Fränkel : Je pense que les tests automatisés et l'intégration continue sont déjà particulièrement bien implantés dans les équipes de développement (surtout celles dans lesquelles j'ai envie de travailler...). Toutefois, ils restent limités aux tests unitaires ; je pense qu'il est nécessaire de passer à l'étape suivante, et les équipes sont prêtes pour cela car elles perçoivent les limites de l'approche actuelle.

InfoQ FR : Tu consacres aussi un chapitre complet aux deux plateformes majeures du développement Java actuel, JavaEE et Spring, et les façons d'exécuter des tests dans leur container. Que penses-tu justement des outils actuels dont tu parles, Arquillian et Spring Test ?

Nicolas Fränkel : De la même manière que les Mocks ont leurs limites, les Fakes en possèdent également. Les containers ont des bugs, et les containers JavaEE ont une marge de manoeuvre dans l'implémentation des spécifications. A ce titre, des outils qui permettent de simplifier l'automatisation des tests in-container sont une excellente nouvelle. Je me souviens encore du projet Jakarta Cactus qui permettait de réaliser de tels tests, mais le déploiement restait le point noir. Arquillian et la partie MVC de Spring Test sont tout simplement géniaux !

InfoQ FR : Merci beaucoup Nicolas et à bientôt !

Nicolas Fränkel : C'était un plaisir ! Si vous êtes intéressés, n'hésitez pas à vous inscrire sur Integration Testing from the Trenches afin d'être prévenus de la première publication (tout bientôt !).

Le livre de Nicolas Fränkel est disponible via la plateforme de publication participative LeanPub à l'adresse suivante : Integration Testing from the Trenches.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT