Dans notre entreprise, nous nous assurons généralement de rédiger un test de bout en bout pour nos sites Web / applications Web. Cela signifie que nous accédons à une URL, remplissons un formulaire, soumettons le formulaire à une autre URL et vérifions les résultats de la page. Nous faisons cela pour tester la validation du formulaire, vérifier que les modèles HTML ont les variables de contexte correctes, etc.
Nous l'utilisons également pour tester indirectement la logique sous-jacente.
Un collègue m'a dit que la raison en est que nous pouvons extraire et modifier l'implémentation sous-jacente à tout moment tant que les tests de bout en bout réussissent.
Je me demande si ce type de découplage est logique ou si c'est juste un moyen d'éviter d'écrire des tests pour des unités de code plus petites?
la source
was told by a co-worker that the reason for this is that we can rip out and change the underlying implementation at any point as long as the end-to-end tests pass.- Cela vaut également pour les tests unitaires. Il me semble que les tests de bout en bout sont utilisés comme excuse pour ne pas écrire de tests unitaires.Réponses:
Des tests de bout en bout sont également nécessaires. Sinon, comment pouvez-vous savoir que vous avez correctement connecté toutes les unités? Sur du code très simple, il est possible de tester tous les chemins à travers le code avec seulement des tests de bout en bout, mais à mesure que vous obtenez plus de couches, cela devient beaucoup plus coûteux de le faire.
Par exemple, supposons que vous ayez trois couches, chacune avec cinq chemins possibles. Pour tester tous les chemins à travers l'application entière, il faudrait 5 3 tests de bout en bout, mais vous pouvez tester tous les chemins à travers chaque unité avec seulement 5 · 3 tests unitaires. Si vous ne faites que des tests de bout en bout, de nombreux chemins finissent par être négligés, principalement dans la gestion des erreurs et les conditions aux limites.
la source
Oui, les tests de bout en bout (ou tests d'intégration) ont beaucoup de sens, mais les tests unitaires aussi. Idéalement, vous les avez tous les deux, car les deux attrapent généralement différents types de bogues. Ainsi, avoir des tests de bout en bout ne devrait jamais être une excuse pour ne pas avoir de tests unitaires.
la source
Après quelques années de codage et de travail sur des projets, je répondrai à ma propre question.
Oui, vous devez écrire des tests unitaires. Les tests de bout en bout sont plus difficiles à écrire et fragiles, surtout s'ils s'appuient sur des composants d'interface utilisateur.
Si vous utilisez un framework comme Django ou Rails (ou vos propres classes personnalisées), vous devriez avoir une classe de formulaire qui gérera la validation du formulaire. Vous aurez également des classes d'affichage qui affichent des modèles rendus et le formulaire et gèrent les demandes GET et POST.
Dans un test de bout en bout, vous devez:
Vous testez beaucoup de code et votre couverture sera plutôt bonne, mais vous ne testez le chemin heureux que lorsque tout va bien. Comment vous assurez-vous que le formulaire contient la bonne validation? Et si ce formulaire est utilisé sur plusieurs pages? Ecrivez-vous encore un autre test de bout en bout?
Essayons à nouveau avec des tests unitaires:
En utilisant des tests unitaires, vous testez des morceaux de code plus petits et les tests sont spécifiques et plus faciles à écrire. Lorsque vous combinez cela avec TDD (Test Driven Development), vous obtenez un code de meilleure qualité.
La facilité d'écriture des tests unitaires ne doit pas être écartée car lorsque vous êtes sur un projet qui n'a pas de test automatisé, vous devez commencer quelque part. Commencer par des tests unitaires est plus facile et plus rapide et vous permet de commencer immédiatement à tester les bogues plutôt que seulement pour le chemin heureux.
la source
En fait, les tests de bout en bout ou les tests d'intégration sont plus importants que les tests unitaires car ils garantissent que vous disposez d'un système pleinement opérationnel. Les tests unitaires ne couvrent pas la partie intégration d'un système, ce qui est une tâche compliquée, en particulier dans les grands projets.
Cependant, comme cela a été dit, vous devriez également faire des tests unitaires, car il est plus compliqué de détecter les cas limites dans les tests d'intégration.
la source
Il vérifie le comportement du système, tandis que les tests unitaires vérifient le comportement de l'unité. Les avantages et les coûts pour chacun sont différents. Vous pouvez faire l'un ou l'autre ou les deux.
Dans mon travail, nous faisons du développement piloté par des tests d'acceptation sans tests unitaires, ce qui ressemble à ce que vous avez décrit. Nous avons commencé à faire les deux et au fil du temps, puis nous avons finalement éliminé les tests unitaires pour un coût dépassant les avantages pour nous.
Cela étant dit, je pense que le rapport coût / avantage pour votre domaine et votre environnement de problème devrait conduire les décisions de s'engager dans n'importe quelle pratique de développement, différentes pratiques de test automatisées incluses. Plutôt que la foi, je préfère que toutes les pratiques aient des preuves empiriques dans le contexte de leur utilisation pour les soutenir.
la source
For Any Practice: Practice iff Benefit > Cost