Ai-je besoin d'un test unitaire si j'ai déjà un test d'intégration?
Si j'ai déjà un test d'intégration pour mon programme, et qu'ils ont tous réussi, alors j'ai une bonne impression que cela fonctionnera. Alors, quelles sont les raisons d'écrire/ajouter des tests unitaires? Comme je dois déjà écrire des tests d'intégration de toute façon, j'aimerai seulement écrire des tests unitaires pour les pièces qui ne sont pas couvertes par les tests d'intégration.
Ce que je sais des avantages du test unitaire par rapport au test d'intégration sont
- Petit et donc rapide à exécuter (mais l'ajout d'une nouvelle unité pour tester quelque chose est déjà testé par le test d'intégration signifie que ma combinaison de test totale devient plus grande et plus longue à exécuter)
- Localisez le bogue plus facilement car il ne teste qu'une seule chose (mais je peux commencer à écrire un test unitaire pour vérifier chaque partie individuelle lorsque mon test d'intégration a échoué)
- Trouvez un bug qui ne peut pas être détecté dans le test d'intégration. par exemple. masquer/compenser les bogues. (mais si mes tests d'intégration réussissent, cela signifie que mon programme fonctionnera même s'il existe des bogues cachés. Donc, trouver/corriger ces bogues ne sont pas vraiment de haute priorité à moins qu'ils ne commencent à casser les futurs tests d'intégration ou à causer des problèmes de performances)
Et nous voulons toujours écrire moins de code, mais les tests unitaires d'écriture ont besoin de beaucoup plus de code (principalement des objets fictifs de configuration). La différence entre certains de mes tests unitaires et de mes tests d'intégration est que dans les tests unitaires, j'utilise un objet factice et dans les tests d'intégration, j'utilise un objet réel. Qui ont beaucoup de duplication et je n'aime pas le code dupliqué, même dans les tests, car cela ajoute une surcharge pour changer le comportement du code (l'outil de refactorisation ne peut pas tout faire tout le temps).
Vous avez présenté de bons arguments pour et contre les tests unitaires. Vous devez donc vous demander: " Est-ce que je vois de la valeur dans les arguments positifs qui l'emportent sur les coûts dans les arguments négatifs? " = Je fais certainement:
- Petit et rapide est un aspect agréable des tests unitaires, bien que nullement le plus important.
- Locating-bug [s] -easier est extrêmement précieux. De nombreuses études sur le développement de logiciels professionnels ont montré que le coût d'un bogue augmente fortement à mesure qu'il vieillit et descend dans le pipeline de livraison de logiciels.
- Trouver des bogues masqués est précieux. Lorsque vous savez qu'un composant particulier a tous ses comportements vérifiés, vous pouvez l'utiliser de manière inutilisée, en toute confiance. Si la seule vérification est via les tests d'intégration, vous savez seulement que ses actuels utilisations se comportent correctement.
- La moquerie est coûteuse dans les cas du monde réel, et le maintien de la simulation l'est doublement. En fait, lorsque vous vous moquez d'objets ou d'interfaces "intéressants", vous pourriez même avoir besoin de tests qui vérifient que vos objets fictifs modélisent correctement vos objets réels!
Dans mon livre, les avantages l'emportent sur les inconvénients.
Je ne vois pas beaucoup de valeur à réimplémenter un test-test d'intégration existant comme un plus simple.
Les tests d'intégration sont souvent beaucoup plus faciles à écrire pour les applications héritées non tdd car généralement les fonctionnalités à tester sont étroitement couplées, de sorte que les unités de test isolées (= non testées) peuvent être difficiles/coûteuses/impossibles.
> Then what are the reasons to write/add unit tests?
À mon avis, le développement piloté par les tests est plus efficace si vous écrivez les tests unitaires avant le code réel. De cette façon, le code qui remplit les tests est clairement séparé avec un minimum de références externes faciles à tester.
Si le code existe déjà sans les tests unitaires, il faut généralement beaucoup de travail supplémentaire pour écrire les tests unitaires par la suite, car le code n'a pas été écrit pour un test facile.
Si vous faites TDD, le code est testable facilement.
Les tests d'intégration doivent uniquement vérifier que plusieurs composants fonctionnent ensemble comme prévu. La précision ou non de la logique des composants individuels doit être vérifiée par des tests unitaires.
La plupart des méthodes ont plusieurs chemins d'exécution possibles; pensez à if-then-else, aux variables d'entrée avec des valeurs inattendues ou tout simplement erronées, etc. Habituellement, les développeurs ont tendance à ne penser qu'au chemin heureux: le chemin normal qui ne va pas mal. Mais en ce qui concerne ces autres chemins, vous avez deux options: vous pouvez laisser votre utilisateur final explorer ces chemins à travers les actions qu'ils entreprennent dans l'interface utilisateur et espérer qu'ils ne plantent pas votre application, ou vous pouvez écrire des tests unitaires qui affirment le comportement de ces autres voies et agir si nécessaire.
Certaines des raisons que vous avez mentionnées dans votre question sont vraiment importantes et pourraient à elles seules plaider en faveur des tests unitaires, mais YMMV. Par exemple, à quelle fréquence exécutez-vous votre suite de tests intégrée? D'après mon expérience avec les tests intégrés, tôt ou tard, ils deviendront si lents que vous ne les exécuterez pas chaque fois que vous apporterez une modification et le temps entre l'insertion et la détection d'un bogue augmentera.
De plus, une grosse erreur que vous pourriez faire est de croire que
Find bug that may not be caught in integration test. e.g. masking/offsetting bugs.
n'est pas important. Vous attendez-vous que vos utilisateurs trouvent les bogues pour vous? Faire confiance à des couvertures obtenues à partir de tests intégrés est dangereux à mon avis, vous pouvez très facilement obtenir un% de couverture élevé mais en réalité vous testez très peu.
Je suppose que la référence canonique contre les tests intégrés sont les messages de JBrains:
http://www.jbrains.ca/permalink/integrated-tests-are-a-scam-part-1
au cas où vous ne les auriez pas déjà lus.
Enfin, l'OMI les commentaires que vous pouvez obtenir des tests unitaires pour votre conception sont inestimables. Juger une conception en se sentant instinctif et en s'appuyant sur des tests intégrés peut également être une erreur.
Si vous vous attendez à devoir modifier ou refactoriser votre code, avoir des tests unitaires est essentiel. Les tests unitaires existent non seulement pour démontrer les bogues au moment où le code est écrit, mais pour montrer quand de nouveaux bogues apparaissent quand plus de code est écrit.
Oui, il est préférable d'écrire d'abord vos tests d'intégration et unitaires, mais il y a beaucoup de valeur à les avoir même s'ils sont écrits plus tard.