Réponse.

Les tests automatiques sont divisés en tests unitaires, tests d'intégration et tests end-to-end (E2E) afin de couvrir de manière globale la vérification du système à différents niveaux.

Historique de la question : Cette classification a émergé de la nécessité de tester les applications à la fois par parties et dans leur ensemble. On distingue donc les couches de tests :

fonction spécifique (unité)
interaction des parties (intégration)
l'ensemble du système fonctionnant comme pour l'utilisateur (E2E)

Problème : Les erreurs se produisent souvent non seulement dans la logique d'une méthode individuelle, mais aussi aux jonctions des composants ou lors du démarrage "réel" de l'ensemble du système avec des services externes. Si tout est mélangé, il est difficile de localiser rapidement un bogue ou de comprendre où il s'est produit.

Solution :

Les tests unitaires vérifient le code isolé, généralement au niveau des fonctions ou des classes simples. Dans des cas avancés, des mocks et des stubs sont utilisés.
Les tests d'intégration relient plusieurs composants (par exemple, un module et une base de données) pour voir comment ils fonctionnent ensemble.
Les tests end-to-end (E2E) imitent les scénarios d'utilisateur — tout le chemin "du bouton au résultat".

Il est vital de distinguer les types de tests pour :

Minimiser le coût de support (les tests E2E sont chers)
Maintenir un retour rapide (les tests unitaires sont instantanés)
Réduire le nombre de faux positifs

Caractéristiques clés :

Une bonne distribution des tests aide à construire une approche "pyramidale" fiable (pyramide de tests).
La confusion dans les styles de tests conduit à des problèmes de localisation des bogues.
Une compréhension claire de la fonction de chaque couche entraîne une efficacité maximale.

Questions pièges.

Les tests d'intégration peuvent-ils être considérés comme de "grands" tests unitaires ?

Non, les tests d'intégration testent le fonctionnement de plusieurs composants ensemble, et non seulement des fonctions individuelles. Dans ce cas, il n'est pas toujours possible d'utiliser des mocks — les services réels interagissent les uns avec les autres.

Tous les tests doivent-ils être end-to-end (E2E) ?

Non, c'est une approche coûteuse et complexe. Les E2E ne sont nécessaires que pour des scénarios utilisateurs critiques, la plupart de la logique est couverte par d'autres tests.

Les tests unitaires sont-ils toujours rapides ?

Pas toujours. Parfois, il est impossible d'isoler le code, ou le fonctionnement d'une méthode dépend de ressources externes complexes. Dans ce cas, le test cesse d'être unitaire.

Erreurs typiques et anti-modèles

Tous les tests sont écrits uniquement en E2E, le retour d'information devient très lent.
Confusion dans les couches : un test unitaire commence à interagir avec la base de données ou l'API, tandis que les E2E sont construits à partir de mocks.
Ils ne laissent que des tests unitaires — des bogues problématiques aux jonctions des composants ne sont pas détectés.

Exemple de la vie

Cas négatif

L'entreprise a couvert sa fonctionnalité principale uniquement avec des tests E2E — chaque modification était vérifiée la nuit, les tests échouaient de façon instable, les bogues étaient découverts tardivement.

Avantages :

Des scénarios réels d'utilisateur sont couverts.

Inconvénients :

Retour d'information lent.
Lento d'analyse des causes des pannes.
Beaucoup de faux positifs.

Cas positif

L'équipe a établi une pyramide de tests : en bas - tests unitaires, au milieu - tests d'intégration, en haut - uniquement les plus importants E2E.