Quoi ne pas tester en matière de tests unitaires?

https://stackoverflow.com/questions/109432

01-07-2019
|

Question

Dans quelles parties d'un projet, l'écriture de tests unitaires est-elle presque ou vraiment impossible? Accès aux données? ftp?

S'il existe une réponse à cette question, la couverture de% 100 est un mythe, n'est-ce pas?

La solution

Ici j'ai trouvé (via piraté quelque chose que Michael Feathers dit que cela peut être une réponse:

Il dit,

Un test n'est pas un test unitaire si:



Il parle à la base de données

Il communique sur le réseau

Cela touche le système de fichiers

Il ne peut pas être exécuté en même temps que vos autres tests unitaires

Vous devez exécuter des tâches spéciales dans votre environnement (telles que l'édition de fichiers de configuration) pour l'exécuter.

Dans le même article, il ajoute:

En général, les tests unitaires sont supposés être petits, ils testent une méthode ou l’interaction de plusieurs méthodes. Lorsque vous insérez la base de données, les sockets ou l'accès au système de fichiers dans vos tests unitaires, ils ne sont plus vraiment concernés par ces méthodes; il s’agit de l’intégration de votre code avec cet autre logiciel.

Autres conseils

Cette couverture à 100% est un mythe, ce qui en fait ne signifie pas qu'une couverture à 80% est inutile. Bien entendu, l'objectif est de 100% et, entre les tests unitaires et les tests d'intégration, vous pouvez l'approcher.

Ce qui est impossible avec les tests unitaires, c'est de prévoir toutes les choses étranges . vos clients feront pour le produit. Une fois que vous avez commencé à découvrir ces perversions ahurissantes de votre code, assurez-vous de renvoyer les tests correspondants dans la suite de tests.

obtenir une couverture de code à 100% est presque toujours une perte de temps. Il existe de nombreuses ressources à ce sujet.

Rien n’est impossible au test unitaire, mais les rendements diminuent toujours. Il se peut que cela ne vaut pas la peine d’essayer à l’unité les choses qui sont douloureuses.

L'objectif n'est pas une couverture de code à 100%, ni une couverture de code à 80%. Un test unitaire facile à écrire ne signifie pas que vous devez l'écrire, et un test unitaire difficile à écrire ne signifie pas que vous devriez éviter l'effort.

Le but de tout test est de détecter les problèmes visibles de l’utilisateur de la manière la plus abordable.

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 résolus par un test spécifique?

Si le problème que le test détecte est "coûteux", vous pouvez vous permettre de faire des efforts pour déterminer comment le tester et le maintenir. Si le problème rencontré par le test est trivial, il est préférable d’écrire (et de maintenir!) Le test (même en présence de modifications du code).

L'objectif principal d'un test unitaire est de protéger les développeurs des erreurs d'implémentation. Cela seul devrait indiquer que trop d'effort sera un gaspillage. Après un certain point, il existe de meilleures stratégies pour obtenir une mise en œuvre correcte. De plus, après un certain point, les problèmes visibles de l'utilisateur sont dus à la mise en œuvre correcte d'une erreur qui ne peut être détectée que par le niveau d'utilisateur ou les tests d'intégration.

Que ne testeriez-vous pas? Tout ce qui ne pourrait pas casser.

En ce qui concerne la couverture de code, vous souhaitez viser 100% du code que vous écrivez réellement, c’est-à-dire que vous n’avez pas besoin de tester le code de la bibliothèque tierce, ni le code du système d’exploitation, car ce code vous aura été livré. Sauf si ce n'est pas. Dans ce cas, vous voudrez peut-être le tester. Ou, s’il existe des bogues connus, dans ce cas, vous voudrez peut-être vérifier la présence des bogues, afin d’avoir une notification du moment où ils auront été corrigés.

Le test unitaire d’une interface graphique est également difficile, bien que pas impossible, je suppose.

L’accès aux données est possible car vous pouvez configurer une base de données de test.

Généralement, les éléments "non testables" sont les suivants: FTP, courrier électronique, etc. Cependant, ce sont généralement des classes d'infrastructure sur lesquelles vous pouvez compter et vous n'avez donc pas besoin de tester si vous les cachez derrière une abstraction.

En outre, une couverture de code à 100% ne suffit pas.

@GarryShutler

En réalité, j’envoie un email en utilisant un faux serveur smtp (Wiser). Assurez-vous que le code de votre application est correct:

http: // maas-frensch.com/peter/2007/08/29/unittesting-e-mail-sending-using-spring/

Quelque chose comme cela pourrait probablement être fait pour d'autres serveurs. Sinon, vous devriez pouvoir vous moquer de l'API ...

BTW: une couverture à 100% n’est que le début ... signifie simplement que tout le code a en fait été exécuté une fois .... rien sur les cas de bords, etc.

La plupart des tests, qui nécessitent des montages énormes et coûteux (en temps de calcul ou en temps de calcul), sont des tests d'intégration. Les tests unitaires devraient (en théorie) seulement tester de petites unités du code. Fonctions individuelles.

Par exemple, si vous testez la fonctionnalité de courrier électronique, il est logique de créer un fictif. Le but de cette simulation est de vous assurer que votre code appelle correctement le courrier. Pour savoir si votre application envoie effectivement un courrier, vous devez effectuer un test d'intégration.

Il est très utile de faire la distinction entre les tests unitaires et les tests d'intégration. Les tests unitaires devraient être très rapides. Il devrait être facilement possible de lancer tous vos tests unitaires avant d’archiver votre code.

Toutefois, si votre suite de tests consiste en de nombreux tests d'intégration (qui configurent et démontent des bases de données, etc.), votre série de tests peut facilement dépasser une demi-heure. Dans ce cas, il est très probable qu'un développeur n'exécute pas tous les tests unitaires avant son enregistrement.

Donc, pour répondre à votre question: effectuez des tests unitaires nets, qui sont mieux implémentés comme test d’intégration (et ne testez pas non plus le getter / le setter - c’est une perte de temps ;-)).

Lors des tests unitaires, vous ne devez tester aucun élément n'appartenant pas à votre unité. tester les unités dans leur contexte est une autre affaire. C'est la réponse simple.

La règle de base que j’utilise est que vous devez tester à l’unité tout ce qui touche les limites de votre unité (généralement la classe, ou quoi que ce soit d'autre que votre unité pourrait être), et vous moquer du reste. Il n'est pas nécessaire de tester les résultats renvoyés par une requête de base de données, il suffit de tester que votre unité crache la requête correcte.

Cela ne signifie pas que vous ne devez pas omettre les éléments difficiles à tester. Même la gestion des exceptions et les problèmes de concurrence peuvent être assez bien testés avec les bons outils.

"Que ne pas tester en matière de tests unitaires?" * Haricots avec juste des geters et des setters. Raisonnement: Habituellement une perte de temps qui pourrait être mieux dépensée à tester autre chose.

Tout ce qui n’est pas complètement déterministe est un non-non pour les tests unitaires. Vous voulez que vos tests unitaires réussissent ou échouent TOUJOURS avec les mêmes conditions initiales - si un facteur étrange tel que le filetage, la génération aléatoire de données, l'heure / la date ou des services externes peuvent avoir une incidence sur cela, vous ne devriez pas le couvrir dans vos tests unitaires. . L'heure / les dates sont un cas particulièrement méchant. Vous pouvez généralement utiliser du code d'architecte pour définir une date à utiliser (par code et tests) plutôt que de vous fier aux fonctionnalités de la date et de l'heure actuelles.

Cela dit, les tests unitaires ne doivent pas être le seul niveau de test de votre application. Atteindre une couverture de 100% des tests unitaires est souvent une perte de temps et répond rapidement à des rendements décroissants.

Il est préférable de disposer d’un ensemble de tests fonctionnels de niveau supérieur, et même de tests d’intégration, afin de s’assurer que le système fonctionne correctement "une fois que tout est réuni" - ce que l’unité teste par définition < strong> ne pas tester.

Tout ce qui nécessite une configuration très volumineuse et compliquée. Bien sûr, vous pouvez tester FTP (client), mais vous devez ensuite configurer un serveur FTP. Pour le test unitaire, vous avez besoin d’une configuration de test reproductible. Si vous ne pouvez pas le fournir, vous ne pourrez pas le tester.

Vous pouvez les tester, mais ils ne seront pas des tests unitaires. Le test unitaire est quelque chose qui ne dépasse pas les frontières, telles que croiser le fil, frapper la base de données, courir / interagir avec une tierce partie, toucher une base de code non testée / héritée, etc.

Au-delà, ce sont les tests d'intégration.

La réponse évidente à la question dans le titre est que vous ne devriez pas tester les composants internes de votre API, vous ne devriez pas vous fier au comportement de quelqu'un d'autre, vous ne devriez pas tester quoi que ce soit dont vous n'êtes pas responsable.

Le reste devrait suffire à vous permettre d’écrire votre code à l’intérieur, pas plus, pas moins.

Certes, une couverture à 100% est un bon objectif lorsque vous travaillez sur un projet volumineux, mais pour la plupart des projets, corriger un ou deux bogues avant le déploiement ne justifie pas nécessairement la création de tests unitaires exhaustifs.

Tester de manière exhaustive des éléments tels que la soumission de formulaires, l'accès à la base de données, l'accès FTP, etc. à un niveau très détaillé est souvent une perte de temps; À moins que le logiciel en cours d’écriture nécessite un niveau de fiabilité très élevé (99,999% des performances), trop de tests unitaires peuvent être excessifs et constituer un puits en temps réel.

Je ne suis pas d'accord avec la réponse de Quamrana concernant le fait de ne pas tester le code tiers. C'est l'utilisation idéale d'un test unitaire. Que se passe-t-il si un ou des bogues sont introduits dans une nouvelle version d'une bibliothèque? Idéalement, lorsqu'une nouvelle bibliothèque tierce version est publiée, vous devez exécuter les tests unitaires qui représentent le comportement attendu de cette bibliothèque pour vérifier qu'elle fonctionne toujours comme prévu.

La configuration est un autre élément très difficile à tester dans les tests unitaires. Les tests d'intégration et autres tests doivent être effectués par rapport à la configuration. Cela réduit la redondance des tests et libère beaucoup de temps. Essayer de configurer les tests unitaires est souvent frivole.

FTP, SMTP et les E / S en général doivent être testés à l’aide d’une interface. L’interface doit être implémentée par un adaptateur (pour le code réel) et une maquette pour le test unitaire.

Aucun test unitaire ne doit exercer la ressource externe réelle (serveur FTP, etc.)

Si le code permettant de définir l'état requis pour un test unitaire devient beaucoup plus complexe que le code à tester, j'ai tendance à tracer la ligne et à trouver un autre moyen de tester la fonctionnalité. À ce stade, vous devez vous demander comment savez-vous que le test unitaire est correct!

FTP, e-mail, etc., vous pouvez tester avec une émulation de serveur. C'est difficile mais possible.

Ne peuvent pas être testés. Dans chaque code, il existe une gestion des erreurs qui ne peut jamais se produire. Par exemple, en Java, il doit y avoir plusieurs exceptions catch, car elles font partie d’une interface. Mais l'instance utilisée ne le lancera jamais. Ou le cas par défaut d'un commutateur si, dans tous les cas possibles, un bloc de cas existe.

Bien sûr, certaines des erreurs de traitement des erreurs peuvent être supprimées. Mais y a-t-il une erreur de codage dans le futur alors c'est mauvais.

Le code de test unitaire est principalement motivé par la validation de la conception de votre code. Il est possible d’obtenir une couverture de code à 100%, mais non sans utiliser des objets fictifs ou une forme quelconque d’isolation ou d’injection de dépendance.

N'oubliez pas que les tests unitaires ne sont pas destinés aux utilisateurs, mais aux développeurs et aux systèmes de construction à utiliser pour valider un système avant sa publication. À cette fin, les tests unitaires doivent être très rapides et présenter le moins de frottement possible en termes de configuration et de dépendance. Essayez de faire tout ce que vous pouvez en mémoire et évitez d’utiliser les connexions réseau des tests.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow