Dans la pyramide des tests de bout en bout (E2E), les tests occupent l'un des échelons supérieurs. En écrivant un test E2E, vous pouvez être sûr des résultats de la logique de votre application, tester les intégrations avec d'autres systèmes et créer un «contrat» pour votre application.
Malheureusement, de nombreux collègues avec lesquels j'ai travaillé n'ont pas écrit de tests E2E. En partie parce qu'ils sont allés tête baissée dans les tests unitaires et ont pensé que c'était mieux pour un certain nombre de raisons, y compris la tendance TDD. En partie parce qu'ils pensaient que les tests E2E sont difficiles à écrire, ils prennent beaucoup de temps à exécuter et il y a des problèmes avec l'instrumentation.
Trions ces opinions et examinons les avantages offerts par les tests E2E.
Terminologie
Mettons le type d'autotests sous les tests E2E. Ces autotests doivent couvrir toutes les fonctions de service du point de vue du client. Ils le font en simulant l'interaction client réelle, qu'il s'agisse d'une requête HTTP ou en cliquant sur un bouton dans l'interface utilisateur.
L'approche des tests unitaires est meilleure
L'écriture de tests unitaires, d'après mon expérience, prend beaucoup plus de temps que les tests E2E. Oui, au début, vous devez comprendre comment les tests E2E sont meilleurs à écrire, mais il en était de même pour les tests unitaires.
D'un autre côté, en conséquence, un test E2E couvre plus de code qu'un test unitaire, bien qu'il puisse prendre moins de lignes par rapport à une suite de tests unitaires similaire.
Vous n'avez pas à perdre de temps à comprendre comment simuler correctement les dépendances, car les systèmes externes les deviennent dans les tests E2E, et l'interaction avec le service testé est construite selon le principe de la «boîte noire».
Vous n'avez pas besoin de vérifier toutes les conditions aux limites pour une méthode de classe unique. Cela augmente la flexibilité de travailler avec le code, car il n'est pas nécessaire de refactoriser l'ensemble de la suite de tests au moindre changement dans la logique interne de l'application.
, , 100 ( ), .
backend- , API HTTP ( GraphQL) MQ. HTTP, mainstream .
Frontend- , , Web- () . , , , .
E2E , . . .. . , .
E2E
, , .
"" code-coverage. , , , , . exception, , ?
, E2E .
E2E API . , backend, E2E , , frontend .
, , E2E , unit-, .
! , E2E ?