Dans quelles parties d'un projet l'écriture de tests unitaires est presque ou vraiment impossible ? Accès aux données ? ftp ?
S'il existe une réponse à cette question, la couverture à 100 % est un mythe, n'est-ce pas ?
Réponses
Trop de publicités?
Aquí J'ai trouvé (via haché Michael Feathers dit que cela peut être une réponse :
Il dit,
Un test n'est pas un test unitaire si
- Il communique avec la base de données
- Il communique à travers le réseau
- Il touche le système de fichiers
- Il ne peut pas être exécuté en même temps que d'autres tests unitaires.
- Vous devez apporter des modifications à votre environnement (comme l'édition de fichiers de configuration) pour le faire fonctionner.
Dans le même article, il ajoute
En général, les tests unitaires sont censés être de petite taille, ils testent une méthode ou l'interaction de quelques méthodes. Lorsque vous intégrez la base de données, les sockets ou l'accès au système de fichiers dans vos tests unitaires, il ne s'agit plus vraiment de ces méthodes, mais de l'intégration de votre code avec cet autre logiciel.
Kevin Little
Points
5406
Le fait que la couverture à 100 % soit un mythe, ce qui est le cas, ne signifie pas que la couverture à 80 % est inutile. L'objectif, bien sûr, est de 100 %, et entre les tests unitaires et les tests d'intégration, on peut s'en approcher.
Ce qui est impossible dans les tests unitaires, c'est de prédire tous les événements totalement imprévisibles. étrange ce que vos clients feront au produit. Une fois que vous commencez à découvrir ces perversions ahurissantes de votre code, veillez à réintégrer les tests correspondants dans la suite de tests.
Aaron Jensen
Points
2751
Atteindre une couverture de code de 100 % est presque toujours une perte de temps. Il existe de nombreuses ressources à ce sujet.
Rien n'est impossible à tester à l'unité, mais il y a toujours des rendements décroissants. Il ne vaut peut-être pas la peine de tester à l'unité des choses qui sont pénibles à tester à l'unité.
Steve Steiner
Points
4044
L'objectif n'est pas de couvrir 100 % du code, ni 80 %. Le fait qu'un test unitaire soit facile à écrire ne signifie pas qu'il faille l'écrire, et le fait qu'un test unitaire soit difficile à écrire ne signifie pas qu'il faille éviter l'effort.
L'objectif de tout test est de détecter les problèmes visibles de l'utilisateur de la manière la plus abordable possible.
Le coût total de la création, de la maintenance et du diagnostic des problèmes signalés par le test (y compris les faux positifs) vaut-il les problèmes détectés par ce test spécifique ?
Si le problème détecté par le test est "coûteux", vous pouvez vous permettre de consacrer des efforts à la recherche d'un moyen de le tester et à la maintenance de ce test. Si le problème détecté par le test est trivial, l'écriture (et la maintenance !) du test (même en présence de modifications du code) a tout intérêt à être trivial.
L'objectif principal d'un test unitaire est de protéger les développeurs contre les erreurs d'implémentation. Ce seul fait devrait indiquer que trop d'efforts seront gaspillés. À partir d'un certain point, il existe de meilleures stratégies pour obtenir une implémentation correcte. De même, à partir d'un certain point, les problèmes visibles par l'utilisateur sont dus à la mise en œuvre correcte de la mauvaise chose, qui ne peut être détectée que par des tests au niveau de l'utilisateur ou des tests d'intégration.
quamrana
Points
6411
Qu'est-ce que vous ne testeriez pas ? Tout ce qui ne peut pas se casser.
En ce qui concerne la couverture du code, vous voulez viser 100 % du code que vous écrivez réellement - c'est-à-dire que vous n'avez pas besoin de tester le code des bibliothèques tierces ou le code du système d'exploitation, puisque ce code vous aura été livré testé. Sauf si ce n'est pas le cas. Dans ce cas, vous voudrez peut-être le tester. Ou s'il y a des bogues connus, auquel cas vous voudrez peut-être tester la présence de ces bogues, de manière à recevoir une notification lorsqu'ils seront corrigés.
