Tests de bout en bout versus tests unitaires, les tests doivent-ils être découplés?
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?
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 53 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.
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.
Après quelques années de codage et de travail sur des projets, je répondrai à ma propre question.
Oui, vous devriez é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 requêtes GET et POST.
Dans un test de bout en bout, vous devez:
- obtenir l'url
- remplissez le formulaire avec des données valides
- poster le formulaire dans l'url
- vérifiez que la base de données a été mise à jour ou qu'une action a été exécutée à la suite du formulaire valide
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:
- tester la méthode GET view
- tester la vue POST avec une forme fake/mock
- tester le formulaire avec des données valides
- tester le formulaire avec des données invalides
- tester les effets secondaires du formulaire
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 aucun 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.
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 Edge dans les tests d'intégration.
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, pour finalement éliminer les tests unitaires au prix 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.