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:
- 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 méthode view POST avec une fausse / fausse forme
- 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 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.
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.