Dans l'ingénierie des tests logiciels, il existe différents niveaux de test. La pyramide ci-dessous, également appelé pyramide de test ou pyramide de Mike Cohn est une parfaite illustration de ce concept.
Sommaire
1. Les tests unitaires
Les tests unitaires servent à vérifier qu'une certaine unité d'un code fonctionne comme prévu. Ces tests sont habituellement codés par les développeurs et permettent de localiser de manière très précise l'origine d'un bogue. Dans un langage orienté objet comme Java, une unité peut être une classe.
En théorie, l'exécution d'un tests unitaire doit se faire en parfaite isolation et doit durer moins d'une seconde. Les classes appelantes sont souvent remplacées par des mocks, des stubs ou par d'autres types de simulacre. Les tests unitaires ne traversent pas de port et leur nombre doit être largement supérieur au nombre de tout autre type de test.
On peut distinguer deux types de test unitaire.
Les tests unitaires « solitaires » où toutes les classes appelées par la classe testée sont remplacées par des simulacres (mock, stub, etc).
Les tests unitaires « sociables » où seuls les collaborateurs lents comme une classe d'accès à une base de données ou d'appels réseaux sont remplacées par des simulacres.
2. Les tests d'intégration
Dans la pyramide de Mike Cohn, les tests d'intégration se situent juste au-dessus des tests unitaires. Ils sont plus lents que les tests unitaires et sont eux aussi codés par les développeurs. Ils permettent de vérifier que la partie du code qui a pour rôle de communiquer avec un composant externe à l'application fonctionne correctement. Ce composant externe peut être une base de données, un service web ou un système de fichiers.
Les tests d'intégration ont un champ d'action étroit et sont localisés au frontière de l'application. Ce type de test nécessite le plus souvent l'exécution de l'application et du composant externe.
Un exemple possible de test d'intégration consisterait à écrire des informations dans la base de données de l'application via l'appel d'une fonction du code, puis de lire cette base de données pour vérifier la présence du résultat attendu.
1. Les tests d'API
La majorité des applications modernes offrent des API qui peuvent être utilisées pour vérifier le bon fonctionnement de la logique métier de l'application. En général, les tests d'api sont situés juste en dessous des tests d'interface utilisateur. Ils ont l'avantage d'être moins fragile et plus rapide que les tests d'interface utilisateur.
Un exemple de test d'api consisterait à envoyer une requête HTTP vers la couche web service de l'application, puis de vérifier la présence du résultat attendu dans la réponse HTTP.
4. Les tests IHM
Au sommet de la pyramide se trouve les tests d'interface utilisateur. Leur objectif est de vérifier en fonction des entrées et des interactions avec l'interface utilisateur, le contenu et l'affichage des données ainsi que le déclenchement des bonnes actions. Ils permettent de contrôler avec un point de vue utilisateur, le bon fonctionnement d'une application.
Les tests d'interface utilisateur peuvent être automatisés grâce à des outils comme Selenium, Protractor, Appium ou QTP. La mise en place d'un environnement complet est nécessaire pour ce type de test.
Note: Avec certains frameworks comme Angular, il est possible de développer des tests unitaires au niveau de la couche interface utilisateur
Références:
- « The Practical Test Pyramid - martinfowler.com »
- « Defining Test Boundaries – An example - simpleorientedarchitecture.com »
- « Testing Strategies in a Microservice Architecture - martinfowler.com »
- « Chapter 2: Key Principles of Software Architecture - microsoft.com »
- « Just Say No to More End-to-End Tests - testing.googleblog.com »