Thibaud Duthoit | Développeur & Entrepreneur, React.js / React Native

Comprendre les différents types de tests

14/06/2019

Pendant longtemps, j’ai été un peu paumé par rapport aux différents types de tests qui existent. On en entend parler dans des articles ou par des collègues, ou bien l’on met en place ces différents types de tests sans même s’en rendre compte.

Mais c’est assez dangereux de mélanger des tests qui servent des objectifs différents. Non seulement un bon test décrit ce qui est testé et comment, mais aussi il doit être placé au bon endroit et garder un focus très ciblé sur ce qui est testé.

Voici une description sommaire, mais compréhensible des différents types de tests que l’on peut retrouver communément dans nos applications.

Les tests unitaires, ou comment tester des briques élémentaires

On commence avec les fondations. À mon sens, ce sont les tests qui apportent le plus de valeur au développeur et au produit.

Ils doivent :

  • tester uniquement un composant individuel, son API et s’assurer qu’il fonctionne comme prévu
  • être très léger en termes de code et de performance
  • renvoyer un bon rapport en cas d’erreur ou de régression

Entendre ici composant comme une partie élémentaire, presque atomique de notre application : une fonction, une classe, un composant d’UI ou un hook en react, un reducer, un controller de route, etc.

Les avantages des tests unitaires sont importants :

  • ils donnent un retour direct en quelques millisecondes sur le code testé.
  • ils permettent d’écrire très facilement des fonctionnalités en TDD
  • ils sont tellement précis que l’on peut connaitre très rapidement la cause d’une régression et la manière de la corriger
  • ils sont rapides à mettre en place et rapide à s’exécuter
  • ils sont simple (et doivent le rester)

Vous l’avez compris, c’est le type de test idéal pour débuter dans le testing automatisé. Ils constituent le socle sur lequel repose la qualité de votre software.

Avec ce type de tests, vous pouvez viser assez facilement une couverture du code proche du 100%, surtout s’ils sont écrits en TDD.

Idéalement, les fichiers de tests devraient se trouver aussi proches du fichier testé. Par exemple :

- src
 - authentication-reducer.ts
 - authentication-reducer.test.ts

Les tests d’intégration, ou comment savoir si les éléments sont correctement branchés ensemble

Les tests d’intégration portent aussi bien leur nom, ils vérifient simplement que les différentes parties de votre programme, que vous avez testé individuellement via des tests unitaires, fonctionnent bien une fois intégrées ensemble.

Si vous utilisez redux, ça pourrait être de tester qu’une action appelée passe bien dans le reducer et modifie bien le store comme prévu.

L’idéal est de tester des cas d’usages réels ou très proches du réel. Pour le back, ça peut être de tester qu’un POST a bien créé une nouvelle entrée en base correctement.

Prenons l’analogie du corps humain. Les tests unitaires vérifient que tel muscle fonctionne bien, tel os est assez solide. Les tests d’intégrations vont vérifier que, avec tel impulsion nerveuse, on devrait voir se lever le bras.

Ces tests apportent beaucoup de valeur aussi a un niveau plus avancé du développement, car certaines régressions arrivent lors de l’ajout d’une librairie, d’un wrapper de composant, d’un changement d’architecture. Et bien que vos tests unitaires peuvent afficher tout vert, vous auriez quand même cassé une fonctionnalité.

Il n’est pas forcément utile de chercher une couverture de code énorme. Ces tests sont plus couteux à maintenir, et il y a plus de chances d’avoir de faux positifs (des tests qui échouent alors que tout va bien).

Néanmoins, il est essentiel de disposer d’au minimum un test de ce type pour chaque point de jonction entre les différentes parties.

Les tests fonctionnels, ou end-to-end

Les tests fonctionnels portent plutôt mal leur nom, c’était la principale source de confusion pour moi. End-to-end leur correspond mieux, que l’on pourrait traduire par tests de bout en bout.

L’objectif ici est de vérifier le fonctionnement d’une fonctionnalité entière du point de vue de l’utilisateur.

C’est le type de test le plus difficile à mettre en place, on le réserve généralement pour vérifier des parcours critiques de l’application comme l’authentification ou l’achat en ligne.

En gros, on utilise des outils qui vont réellement utiliser notre service, comme un utilisateur physique, généralement via des VM, et effectuer une suite d’action. Par exemple :

  • Se rendre à telle URL
  • Remplir le champ email
  • Remplir le champ password
  • Cliquer sur “Se connecter”
  • Attendre 1 seconde
  • Vérifier que l’on voit son email affiché dans le menu

Ce petit parcours permet tout simplement de tester que l’authentification fonctionne correctement pour le cas nominal.

Ces tests sont couteux à mettre en place car ils nécessitent de bons outils, généralement payants ou longs à mettre en place. Ils sont aussi beaucoup plus longs à s’exécuter que les autres types de tests car ils ont souvent besoin de faire des requêtes web par exemple.

Mais ils restent la meilleure façon de vérifier que les parties les plus critiques de notre application fonctionnent bien et ne subissent pas de régression.

Bonus : Snapshot et smoke tests

Les snapshots sont une façon d’écrire des tests unitaires. Grosso modo, on écrit le test juste en donnant une description et en passant des arguments à notre fonction/classe que l’on veut tester. Et notre outil va générer une représentation (en JSON par exemple) du résultat.

À partir de là, on va sauvegarder cette capture de l’état du résultat en fonction des entrées données, et le verrouiller. Concrètement, si quelqu’un modifie notre fonction et que le résultat change, le test va échouer.

Le développeur qui verra échouer ce snapshot va alors devoir vérifier que le changement est bien désiré, ou s’il s’agit d’une régression. Si le nouveau résultat doit remplacer l’ancien, alors l’outil mettra à jour le snapshot et le test repassera au vert.

À mon humble avis, les snapshots sont une mauvaise idée. Bien qu’ils soient faciles à comprendre et à mettre en place, ils échouent sur plusieurs points plus importants :

  • pas de TDD possible, le snapshot étant généré après l’écriture de la fonctionnalité (et écrire des résultats attendus en JSON est contre-productif)
  • les tests passent au rouge très souvent, la majorité du temps pour des changements désirés. Or le but des tests, c’est d’attraper des régressions, pas des changements
  • il n’est pas toujours facile de s’y retrouver dans la capture, et le temps de débug est souvent plus long pour comprendre l’origine d’une régression comparé à un test classique où l’on va pouvoir jouer avec le code autour du test
  • il est très facile de cliquer sur “Mettre à jour les snapshots” dès que ça passe au rouge, surtout pour des développeurs un peu trop confiants sur leurs modifications. Et il est très difficile pour un relecteur de faire la différence entre un snapshot mis à jour pour modification désirée ou mis à jour avec une régression

Pour toutes ces raisons, j’ai arêter de pratiquer cette méthode de tests unitaires.

Quant aux smoke tests, il s’agit en fait d’une suite de tests déjà décrits précédemment (généralement des tests d’intégrations ou fonctionnels) qui sont lancés juste après un déploiement pour s’assurer que les parties critiques de l’application n’ait pas été impactés par la mise à jour.

En plus de ces smoke tests, je recommande de lancer votre suite de tests unitaires et fonctionnels à chaque commit, et la batterie complète de tous les tests à chaque push sur l’intégration continue (ou en local à défaut).


Thibaud Duthoit

Je m'appelle Thibaud Duthoit, et je suis développeur front-end depuis 5 ans, spécialisé en React.js et React Native.

Vous avez un projet startup web ou mobile ? Vous êtes au bon endroit !

J'ai conçu ou contribué sur le front-end de plus de 14 projets startups, seul ou en équipe.

Vous avez déjà une équipe ? Je coache aussi des développeurs pour les aider à monter en compétence sur React.

Et si vous n'êtes qu'au stade de l'idée, je peux vous accompagner pour chiffrer les coûts de développements de votre projet.

Ma plus-value, c'est ma passion pour le code de qualité, sans bugs et bien testé. Avec moi, vous aurez l'assurance d'un produit de grande qualité technique et facilement maintenable sur le long terme.

Contactez-moi !