L’article d’introduction débute en listant certaines différences de visions que je peux avoir avec d'autres développeurs concernant l'architecture applicative ou encore la rédaction des tests. À travers elles, j’évoque les difficultés qu’ils peuvent rencontrer à identifier précisément quoi tester et comment.
Nous avons pu voir dans les autres articles de la série différents types de tests. Certains nous aidant à vérifier les règles métier comme les tests unitaires :
Ou encore les tests d’acceptation.
Alors que d’autres vont nous permettre de se focaliser sur les implémentations :
Mais à aucun moment on va vouloir tester réellement si toutes ces touches fonctionnent correctement entre elles.
Dans cet article, nous allons combler ce vide en parlant des tests de bout en bout.
Comme son nom l’indique, ce type de test a pour but de vérifier toute la chaîne, en mode boîte noire. Il est très orienté utilisation métier de l’application.
Ils ont en point d'entrée les Adaptateurs de gauche. Ils sont couplés aux différents choix d'implémentation et à ce que l’utilisateur fait.
Exemple : “quand l'utilisateur clique sur ce bouton, il se passe ça”
Au même titre que les tests d’intégration, ils n’ont pas pour vocation de vérifier les règles métiers ou leur orchestration. On souhaite juste savoir si toutes les parties fonctionnent bien entre elles. On fera en général un ou quelques cas passant, comme un chemin critique et non-passant, si ces derniers existent.
Les tests de bout en bout peuvent paraître séduisants pour tester son projet car ils passent partout en plus de décrire des scénarios que l’utilisateur peut réaliser.
Mais si le code est uniquement testé avec cette typologie, certains inconvénients vont apparaître :
NDR : Il peut être intéressant de remplacer les tests d’intégration des composants front-end par des tests e2e, ce qui rend plus malléable le refactoring de ces derniers.
De manière non exhaustive, on pourrait les séparer en deux grosses catégories :
Finalement, il nous reste les tests manuels ou exploratoires qui sont en général effectués par un QA. Son rôle est de voir comment se comporte l'application en la malmenant et en testant des cas non prévus à la base, comme pourrait le faire un utilisateur lambda. Elle n’a pas pour rôle premier de s’assurer que les règles métier sont bien implémentées car cela est déjà vérifié par des tests automatisés.
Il existe plusieurs types de tests qui permettent de vérifier l’application dans sa globalité.
Nous garderons en tête qu’ils ne peuvent en aucun cas remplacer les tests unitaires qui n’ont pas les inconvénients énumérés dans l’article. Au mieux, ça sera un plus, au pire ils ne seront pas présents.
L’un qui est automatisé :
Un test de bout en bout a en point d’entrée un Adaptateur de gauche.
L'objectif est de tester que l’ensemble du système fonctionne correctement avec les différentes couches connectées.
Ils n’ont pas pour objectif de valider des règles métier, c’est pourquoi nous choisirons de faire des scénarios de chemins critiques, par exemple.
L’autre qui a vocation d’être exploratoire et est réalisé à la main :
Un test manuel a forcément en point d’entrée un Adaptateur de gauche. Leur rôle n’est pas de s’assurer que les règles métier sont bien implémentées car cela est déjà vérifié par des tests automatisés.
L'objectif est de se mettre à la place d’un utilisateur lambda et de tester le comportement de l’application en la malmenant et en vérifiant des cas non prévus à la base.
Résumé en une image :
