Ma réponse? Peut-être, probablement pas .
Les tests EOE sont bons lorsqu'ils sont très simples. Si vous prévoyez de couvrir des scénarios de base, vous pouvez réussir à obtenir un certain avantage avec les tests EOE. Mais si vous avez une application vraiment complexe et volumineuse (mission critique ou non), ces tests EOE seront coûteux à maintenir et vous devez connaître votre scénario pour évaluer s'il en vaut la peine.
Il y a quelques années, le blog des tests Google abordait ce sujet. Je ne peux qu'être d'accord avec l'auteur. Un bon test doit être rapide , fiable et isoler les défaillances , des fonctionnalités que les tests EOE ne sont pas capables de vous fournir.
J'ai travaillé sur une application qui a plus de 12 heures de tests de bout en bout couvrant de nombreux scénarios. Finalement, nous avons réussi à distribuer ces tests sur différentes machines, en contrôlant le début, l'exécution et la fin des tests, en collectant et en fusionnant les résultats. L'application testée était une application monolithique (ce qui est plus facile à installer et à exécuter pour tester) et était un cauchemar pour maintenir les tests.
La plupart du temps, nous maintenions les tests au lieu d'attraper des bogues à partir de leurs résultats. Découvrir l'origine d'un bug sur un test de bout en bout prend beaucoup de temps. Nous avons également traité de nombreux tests «faux négatifs» et peu de temps pour comprendre le problème et le corriger: problèmes de chargement de l'applet Java, élément attendu introuvable sur la page (ainsi que d'autres problèmes de vitesse d'automatisation), conserver le code de requête qui sont juste utilisés sur le test de mémoire de la base de données (car la requête d'origine utilise un code spécifique à la base de données), etc.
Tout cela a besoin de personnel pour rester opérationnel. À la fin, nous commençons à supprimer certains tests EOE et à les remplacer par de nombreux tests unitaires / d'intégration.
Donc, mon conseil prudent est d'utiliser la pyramide de test de Google:
À titre de bonne première supposition, Google suggère souvent une répartition 70/20/10: 70% de tests unitaires, 20% de tests d'intégration et 10% de tests de bout en bout. Le mélange exact sera différent pour chaque équipe, mais en général, il devrait conserver cette forme de pyramide.