🌙 🚀 🦊 Dites simplement non aux tests end-2-end 🧢 😱 🙀

Vous avez probablement eu cela quand vous et vos amis vouliez vraiment regarder un film, puis vous avez regretté d'avoir passé du temps dessus. Ou peut-être vous souvenez-vous du moment où votre équipe a pensé qu'elle avait trouvé une «fonction de tueur» et n'a trouvé ses «pièges» qu'après la sortie du produit.

Les bonnes idées échouent souvent dans la pratique, et dans le monde des tests, une stratégie de test basée sur l'automatisation des tests de bout en bout en est un bon exemple.

Les testeurs peuvent investir leur temps à écrire de nombreux types de tests automatisés, y compris les tests unitaires, les tests d'intégration et les tests de bout en bout, mais cette stratégie vise principalement les tests de bout en bout qui testent le produit ou le service dans son ensemble. En règle générale, ces tests imitent des scénarios d'utilisateurs réels.

La source

Tests end-2-end en théorie

Bien que s'appuyer principalement sur des tests end-2-end soit une mauvaise idée, en théorie, vous pouvez trouver plusieurs arguments en faveur de cette affirmation.

Ainsi, le numéro un sur la liste de Google de dix choses qui, comme nous le savons, est vrai: "Les intérêts des utilisateurs avant tout." Ainsi, l'utilisation de tests end-2-end qui se concentrent sur des scénarios d'utilisateurs réels semble être une excellente idée. En outre, cette stratégie est généralement intéressante pour de nombreux participants au processus.

Les développeurs aiment cette stratégie, car vous pouvez transférer la plupart des tests, sinon tous, à d'autres.
, , , , , , .
, , ; .

End-2-end

Donc, si cette stratégie de test semble si bonne en théorie, qu'est-ce qui ne va pas dans la pratique? Pour le démontrer, je donnerai un scénario fictif ci-dessous, mais qui est basé sur des situations réelles qui me sont familières et à celles d'autres testeurs.

Supposons qu'une équipe crée un service de modification de documents en ligne (par exemple, Google Docs). Supposons que l'équipe dispose déjà d'une infrastructure fantastique pour les tests. Toutes les nuits:

Construit la dernière version du service,
puis cette version est déployée dans l'environnement de test en équipe,
puis dans cet environnement de test, tous les tests de bout en bout sont exécutés,
L'équipe reçoit un rapport par e-mail résumant les résultats du test.

La date limite approche à grands pas. Pour maintenir un haut niveau de qualité du produit, disons que nous décidons qu'au moins 90% des tests fin-2-bout réussis sont nécessaires pour que nous considérions que la version est prête. Disons que le délai arrive en un jour.

Malgré de nombreux problèmes, les tests ont finalement révélé de réelles erreurs.

Ce qui s'est bien passé Les

erreurs affectant l'utilisateur ont été identifiées et corrigées avant de l'atteindre.

Quelque chose a mal tourné

L'équipe a terminé sa phase de programmation une semaine plus tard (et a fait beaucoup d'heures supplémentaires).
La recherche de la cause première de l'échec du test end-2-end prend du temps et peut prendre beaucoup de temps.
Les pannes de l'équipe parallèle et les dysfonctionnements de l'équipement ont déplacé les résultats des tests de plusieurs jours.
De nombreuses erreurs mineures étaient cachées derrière de grosses erreurs.
Les résultats des tests de bout en bout ont parfois été peu fiables.
Les développeurs ont dû attendre le lendemain pour savoir si le correctif fonctionnait ou non.

Donc, maintenant que nous savons ce qui n'a pas fonctionné dans la stratégie end-2-end, nous devons changer notre approche de test pour éviter bon nombre des problèmes ci-dessus. Mais quelle est la bonne approche?

La vraie valeur des tests

En règle générale, le travail du testeur se termine lorsque le test échoue. L'erreur est consignée, puis la tâche du développeur consiste à corriger l'erreur. Cependant, pour déterminer où la stratégie end-2-end ne fonctionne pas, nous devons aller au-delà de cette réflexion et aborder le problème en utilisant nos principes de base. Si nous «nous concentrons sur l'utilisateur (et tout le reste suit)», nous devons nous demander: le test échoué profite-t-il à l'utilisateur?

Voici la réponse: "Un test ayant échoué ne profite pas directement à l'utilisateur."

Bien que cette déclaration, à première vue, semble choquante, elle est vraie. Si le produit fonctionne, il fonctionne, que le test indique qu'il fonctionne ou non. Si un produit est cassé, il est cassé, que le test indique qu'il est cassé ou non. Donc, si les tests échoués ne profitent pas à l'utilisateur, qu'est-ce qui lui profite?

Les corrections de bogues profitent directement à l'utilisateur.

L'utilisateur ne sera heureux que lorsque ce comportement imprévisible (erreur) disparaîtra. Évidemment, pour corriger une erreur, vous devez savoir qu'elle existe. Pour savoir qu'une erreur existe, idéalement, vous devriez avoir un test qui la détecte (car si le test ne détecte pas l'erreur, l'utilisateur la trouvera). Mais tout au long de ce processus, de l'échec du test à la correction de l'erreur, la valeur ajoutée apparaît à la toute dernière étape.

Ainsi, pour évaluer une stratégie de test, vous ne pouvez pas simplement évaluer comment il trouve des erreurs. Vous devez également évaluer comment cela permet aux développeurs de les corriger (et même de les empêcher).

Créer la bonne rétroaction

Les tests créent une boucle de rétroaction qui informe le développeur si le produit fonctionne ou non. Une boucle de rétroaction idéale a plusieurs propriétés.

. , , . ( ), . . , .
. , , , . , , .
Il devrait vous permettre de trouver rapidement des erreurs. Pour corriger l'erreur, les développeurs doivent trouver les lignes de code spécifiques à l'origine de l'erreur. Lorsqu'un produit contient des millions de lignes de code et que l'erreur peut être n'importe où, c'est comme essayer de trouver une aiguille dans une botte de foin.

Pensez petit, pas grand

Alors, comment pouvons-nous créer cette boucle de rétroaction parfaite? En pensant au petit, pas au plus grand.

Tests

unitaires Les tests unitaires prennent un petit morceau du produit et le testent indépendamment de tout le reste. Ils créent presque la même boucle de rétroaction parfaite:

Les tests unitaires sont rapides. Nous devons écrire un petit bloc de code et nous pouvons déjà le tester. Les tests unitaires sont généralement assez petits. En fait, un dixième de seconde est trop long pour les tests unitaires.
. , , . , — , , — .
. , , , , .

La rédaction de tests unitaires efficaces nécessite des compétences dans des domaines tels que la gestion des dépendances, la rédaction de talons / simulations et des tests rigoureux. Je ne décrirai pas ces compétences ici, mais pour commencer, l'exemple typique offert au nouveau Googler (ou comme on les appelle dans Google, le Noogler) est de savoir comment Google crée et teste le chronomètre.

Tests unitaires par rapport aux tests end-2-end

Pour les tests end-2-end, vous devez attendre: d'abord pour créer l'intégralité du produit, puis pour le déployer, et enfin pour terminer tous les tests end-2-end. Lorsque les tests fonctionnent toujours, il est très probable qu'ils échouent périodiquement. Et même si le test détecte une erreur, elle peut se trouver n'importe où dans le produit.

Bien que les tests de bout en bout soient plus efficaces pour modéliser des scénarios d'utilisateurs réels, cet avantage est rapidement compensé par toutes les lacunes de la boucle de rétroaction de bout en bout:

Tests d'intégration Les tests

unitaires ont un inconvénient majeur: même si les modules fonctionnent bien séparément, vous ne savez pas s'ils fonctionnent bien ensemble. Mais même dans ce cas, vous n'avez pas à exécuter des tests de bout en bout. Vous pouvez utiliser le test d'intégration pour cela. Le test d'intégration prend un petit groupe de modules, souvent deux, et teste leur comportement dans son ensemble.

Si les deux blocs ne s'intègrent pas correctement, pourquoi écrire un test de bout en bout alors que vous pouvez écrire un test d'intégration beaucoup plus petit et plus ciblé qui détecte la même erreur? Bien sûr, vous devez comprendre tout le contexte lors des tests, mais pour tester ensemble le travail de deux modules, il vous suffit d'élargir un peu la perspective.

Pyramide de test

Même avec les tests unitaires et d'intégration, vous aurez probablement besoin d'un petit nombre de tests end-2-end pour tester le système dans son ensemble. Pour trouver le bon équilibre entre les trois types de tests, il est préférable d'utiliser une pyramide de tests visuels. Voici une version simplifiée de la pyramide de test du discours d'ouverture de la conférence Google Test Automation 2014 .

La majeure partie de vos tests sont des tests unitaires au bas de la pyramide. À mesure que vous montez dans la pyramide, vos tests deviennent plus complets, mais en même temps, le nombre de tests (la largeur de votre pyramide) diminue.

Dans le bon sens, Google propose une séparation 70/20/10: 70% tests unitaires, 20% tests d'intégration et 10% tests end-2-end. Le rapport exact sera différent pour chaque équipe, mais en général, il devrait conserver la forme de la pyramide. Essayez d'éviter les «formulaires» suivants:

Pyramide inversée / cornet de crème glacée. L'équipe s'appuie principalement sur des tests de bout en bout, utilisant plusieurs tests d'intégration et très peu de tests unitaires.
Sablier. L'équipe commence par un grand nombre de tests unitaires, puis utilise des tests de bout en bout où les tests d'intégration doivent être utilisés. Le sablier a de nombreux tests unitaires en bas et de nombreux tests de bout en bout en haut, mais peu de tests d'intégration au milieu.

Tout comme une pyramide ordinaire a tendance à être la structure la plus stable dans la vie réelle, une pyramide de test a également tendance à être la stratégie de test la plus stable.

Travaux

Si vous aimez et savez écrire des tests unitaires, alors vous êtes les bienvenus! La société LANIT a ouvert un poste vacant pour le développeur Java dans l'équipe DevOps, où vous trouverez des personnes partageant les mêmes idées.

Dites simplement non aux tests end-2-end