Quels sont les inconvénients des tests automatisés?

49

Ce site contient un certain nombre de questions qui fournissent de nombreuses informations sur les avantages pouvant être tirés des tests automatisés. Mais je n'ai rien vu qui représente le revers de la médaille: quels sont les inconvénients? Tout dans la vie est un compromis et il n’ya pas de solution miracle, il doit donc exister des raisons valables de ne pas faire de test automatisé. Que sont-ils?

En voici quelques-unes:

  • Nécessite plus de temps de développement initial pour une fonctionnalité donnée
  • Nécessite un niveau de compétence supérieur des membres de l'équipe
  • Augmenter les besoins en outillage (testeurs, frameworks, etc.)
  • Une analyse complexe est nécessaire lorsqu'un test a échoué - ce test est-il obsolète en raison de mon changement ou est-il en train de me dire que j'ai commis une erreur?

Edit
Je devrais dire que je suis un grand partisan des tests automatisés et que je ne cherche pas à être convaincu de le faire. Je cherche à comprendre quels sont les inconvénients, alors quand je vais dans mon entreprise pour faire valoir mes arguments, je ne donne pas l’impression que je jette la prochaine balle en argent imaginaire.

De plus, je ne cherche pas explicitement à quelqu'un pour contester mes exemples ci-dessus. Je prends pour vrai qu'il doit y avoir des inconvénients (tout ce qui a des compromis) et je veux comprendre ce que sont ces avantages.

RationalGeek
la source
18
"Analyse complexe requise ..." le test n'est pas la cause de l'échec, c'est un indicateur. Dire qu'il n'y a pas de test signifie qu'aucune analyse d'échec complexe n'est requise, ce n'est pas mieux que de s'enfoncer la tête dans la boue.
P.Brian.Mackey
1
* des temps de construction plus longs lorsque les tests sont exécutés à chaque construction, et du code répété lorsque les tests sont au niveau très bas (testeurs de getters et de réglages)
freak freak
2
1. Si un développeur utilise son temps pour tester de nouvelles fonctionnalités, le risque d'échec de celles-ci a diminué, ce qui signifie que votre produit est plus stable. 2. Eduquer les membres de votre équipe en vue d'une approche centrée sur le test est une bonne chose. Ils peuvent utiliser cette connaissance pour d'autres tâches au travail (et dans la vie). 3. Créez une installation automatisée pour l'environnement de test 4. Cela me dit qu'un test en fait trop.
CS01
1
Si le même développeur code les tests et le code, ils ne penseront alors qu'aux mêmes cas de test pour lesquels écrire les tests, comme ceux auxquels ils avaient pensé au moment de coder.
Paul Tomblin
Je viens de poster une réponse à la question correspondante et je me sens obligé de commenter au moins celle-ci. OMI, presque tous les inconvénients mentionnés ici (et dans les réponses) semblent faux et trompeurs si nous parlons du vrai projet réel et non de quelque chose que vous codez rapidement et que vous oubliez. Je crains que cette question comme celle-ci ne soit utilisée comme prétexte pour se développer sans tests automatiques et dans de nombreux cas, cela conduira à la mort du projet ou à un rewire complet.
Boris Serebrov

Réponses:

26

Vous avez à peu près cloué les plus importants. J'ai quelques ajouts mineurs, ainsi que l'inconvénient de réussir des tests - quand vous ne le souhaitez pas vraiment (voir ci-dessous).

  • Temps de développement: avec le développement piloté par les tests, celui-ci est déjà calculé dans les tests unitaires, mais vous avez toujours besoin de tests d'intégration et de système, qui peuvent également nécessiter un code d'automatisation. Le code écrit une fois est généralement testé sur plusieurs étapes ultérieures.

  • Niveau de compétence: bien sûr, les outils doivent être pris en charge. Mais ce n'est pas seulement votre propre équipe. Dans le cas d'un projet plus important, vous pouvez avoir une équipe de test séparée qui écrit des tests pour vérifier les interfaces entre le produit de votre équipe et les autres. Tant de gens doivent avoir plus de connaissances.

  • Besoin d'outillage: vous êtes sur place. Pas grand chose à ajouter à cela.

  • Tests ayant échoué: C'est le vrai bugger (pour moi en tout cas). Il y a une foule de raisons différentes, chacune pouvant être considérée comme un désavantage. Et le plus gros désavantage est le temps nécessaire pour décider laquelle de ces raisons s’applique réellement à votre test ayant échoué.

    • échoué, à cause d'un bug réel. (juste pour l'exhaustivité, comme c'est bien sûr avantageux)
    • a échoué car votre code de test a été écrit avec un bogue classique.
    • a échoué car votre code de test a été écrit pour une version plus ancienne de votre produit et n'est plus compatible
    • a échoué, car les exigences ont changé et le comportement testé est maintenant considéré comme "correct"
  • Tests non échoués: ils constituent également un inconvénient et peuvent être très mauvais. Cela arrive surtout lorsque vous changez les choses et que vous vous rapprochez de ce qu'Adam a répondu. Si vous modifiez quelque chose dans le code de votre produit, mais que le test ne la prend pas en compte, cela vous donne ce "faux sentiment de sécurité".

    Un aspect important des tests non échoués est qu'un changement d'exigences peut entraîner l'invalidité d'un comportement antérieur. Si vous avez une traçabilité correcte, le changement d'exigence devrait pouvoir être adapté à votre code de test et vous savez que vous ne pouvez plus faire confiance à ce test. Bien entendu, le maintien de cette traçabilité est un autre inconvénient. Et si vous ne le faites pas, vous vous retrouvez avec un test qui n'échoue pas, mais qui vérifie réellement que votre produit fonctionne mal . Quelque part dans le futur, cela vous frappera .. généralement quand et où vous vous y attendez le moins.

  • Coûts de déploiement supplémentaires: vous n’exécutez pas simplement des tests unitaires en tant que développeur sur votre propre ordinateur. Avec les tests automatisés, vous voulez les exécuter sur des commits d'autres personnes situées à un endroit central pour savoir quand quelqu'un a interrompu votre travail. C'est bien, mais il faut aussi le configurer et le maintenir.

Franc
la source
1
En cas d'échec des tests, si les exigences changent et entraînent l'échec des tests actuels, le test réussit car l'implémentation précédente n'est plus valide. Si cela
échouait,
Le cas 4 (b) est l’essentiel du développement piloté par les tests: vous écrivez un test qui échoue, puis vous étendez le produit, puis vous vérifiez que cette modification assure la réussite du test. Cela vous protège contre un test écrit erroné qui réussit ou échoue toujours.
Kilian Foth
@Frank merci pour la réponse. Il y a beaucoup de perspicacité là-bas. J'ai particulièrement apprécié les distinctions de différentes causes d'échec des tests. Les coûts de déploiement supplémentaires constituent un autre excellent point.
RationalGeek
Ce qui est amusant, c’est que mon ratio bug / LOC est bien pire pour les tests que pour le code réel. Je passe plus de temps à trouver et à corriger des bugs de test que de vrais. :-)
Brian Knoblauch
a échoué car votre code de test a été écrit pour une version plus ancienne de votre produit et n'est plus compatible. Si vos tests échouent à cause de cela, il est probable que vos tests testent les détails d'implantation plutôt que le comportement. CalculateHighestNumber v1 devrait toujours renvoyer le même résultat que CalculateHighestNumber v2
Tom Squires
29

Comme nous venons juste de commencer à essayer des tests automatisés dans notre équipe, le principal inconvénient que j’ai vu est qu’il est très difficile de s’appliquer à du code hérité qui n’était pas conçu pour des tests automatisés. Cela améliorerait sans aucun doute notre code à long terme, mais le niveau de refactorisation nécessaire pour les tests automatisés tout en préservant notre santé mentale constitue un très haut obstacle à l'entrée à court terme, ce qui signifie que nous devrons être très sélectifs quant à l'introduction de la tests unitaires afin de respecter nos engagements à court terme. En d'autres termes, il est beaucoup plus difficile de rembourser les cartes de crédit lorsque vous êtes déjà lourdement endetté.

Karl Bielefeldt
la source
2
En tant que personne travaillant à 80% d'une très grande base de code existante, je suis tout à fait d'accord. Cependant, pour atténuer cela, j'ai utilisé une partie de cela dans [link] amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/… valent le coup d'oeil.
DevSolo
1
C'est un très bon livre, j'en ai tiré beaucoup. Trois points principaux, essayez-vous, un peu à la fois. Certains bons tests valent mieux que pas de tests. Restez à l'écoute, ne refactorisez pas tout ce qui doit être refactoré à la fois. Soyez très clair sur les limites entre le code testable et non vérifiable. Assurez-vous que tout le monde le sait aussi.
Tony Hopkinson
21

Le désavantage le plus important est peut-être ... les tests sont le code de production . Chaque test que vous écrivez ajoute du code à votre base de code qui doit être maintenu et pris en charge. Ne pas le faire conduit à des tests dont vous ne croyez pas les résultats, vous n'avez donc pas d'autre choix. Ne vous méprenez pas, je suis un grand partisan des tests automatisés. Mais tout a un coût, et celui-ci est important.

Ross Patterson
la source
Bon point Ross, c’est une façon intéressante de le dire.
RationalGeek
D'accord, bien que, selon mon expérience, le temps gagné grâce aux tests unitaires permettant de trouver instantanément des bogues potentiels dans le code nouvellement écrit (par exemple, les tests de régression) a dépassé ce temps de maintenance supplémentaire.
dodgy_coder
15

Je ne dirais pas que ce sont des inconvénients entièrement applicables, mais les quelques-uns que je touche le plus sont:

  • Temps nécessaire pour configurer le test dans une application d'entreprise complexe.
  • Traitement des anciens tests qui échouent de manière incorrecte, autrement dit, le système a évolué et maintenant les tests sont erronés.
  • Fausse confiance dans une couverture de test inégale ou inconnue.

Une couverture de test inégale peut conduire à un faux sentiment de sécurité. Si vous effectuez une refactorisation et utilisez les tests pour prouver sa validité, qu'est-ce qui a prouvé que vos tests sont en mesure de le prouver?

Le temps nécessaire pour créer le test est parfois un problème pour nous. Nos tests automatisés ne comprennent pas uniquement des tests unitaires, mais également des tests de cas d'utilisation. Celles-ci ont tendance à être plus larges et nécessitent un contexte.

Bien sûr, mon point de vue est celui d'une application plus ancienne que les tests unitaires.

Adam Houldsworth
la source
Le PO couvrait déjà le temps et le code obsolète dans la question.
P.Brian.Mackey
@ P.Brian.Mackey l'élément temps est en fait subjectif. Le temps nécessaire pour coder le test est différent du temps nécessaire pour comprendre les exigences du test et coder correctement le test.
Adam Houldsworth
@AdamHouldsworth Merci, voici quelques bons exemples d'inconvénients. Je n'avais pas vraiment envisagé le faux angle de confiance.
RationalGeek
9

Je dirais que le principal problème avec eux est qu'ils peuvent donner un faux sentiment de sécurité . Ce n’est pas parce que vous avez des tests unitaires qu’ils font quoi que ce soit et cela inclut de tester correctement les exigences.

En outre, les tests automatisés peuvent également inclure des bogues eux - mêmes , ce qui soulève la question de savoir si les tests unitaires doivent être testés eux-mêmes, donc sans résultat.

billy.bob
la source
Le développement piloté par les tests facilite le premier en demandant qu'un test ait échoué avant d'écrire le code de fonction. Vous savez maintenant que si la fonctionnalité est interrompue, le test le sera. Pour le second, le code de test compliqué est une odeur de code. Encore une fois, en écrivant le test en premier, vous pouvez vous efforcer de simplifier les choses et de placer le travail difficile dans le code de fonction qui corrige le test.
David Harkness
Le code étant difficile à tester n'est pas une odeur de code. Le code le plus facile à tester est une chaîne géante d’appels de fonctions se faisant passer pour des classes.
Erik Reppen
4

Bien que les tests d'automatisation présentent de nombreux avantages, ils présentent également des inconvénients. Certains des inconvénients sont:

  • Maîtriser les scripts de test d'automatisation est indispensable.
  • Le débogage du script de test est un problème majeur. Si une erreur est présente dans le script de test, cela peut parfois entraîner des conséquences mortelles.
  • La maintenance des tests est coûteuse dans le cas des méthodes de lecture. Même si une modification mineure se produit dans l'interface graphique, le script de test doit être réenregistré ou remplacé par un nouveau script de test.
  • La maintenance des fichiers de données de test est difficile si le script de test teste plusieurs écrans.

Certains des inconvénients ci-dessus soustraient souvent les avantages tirés des scripts automatisés. Bien que les tests d'automatisation comportent des avantages et des inconvénients, ils sont largement adaptés dans le monde entier.

Jameswood037
la source
Merci. Bons points. J'ai édité votre message pour la grammaire et le formatage. J'espère que ça ne vous dérange pas.
RationalGeek
3

J'ai récemment posé une question sur les tests de développement de jeux vidéo - voici comment j'ai su à propos de celui-ci. Les réponses ont mis en évidence des inconvénients curieux et spécifiques:

  1. Il est coûteux à réaliser lorsque votre code doit être fortement couplé .
  2. Il est difficile de connaître les différentes plates-formes matérielles, d'analyser le résultat pour l'utilisateur et que le résultat du code n'a de sens que dans un contexte plus large .
  3. Les tests d'interface utilisateur et UX sont très difficiles .
  4. Et notamment, les tests automatisés peuvent être plus coûteux et moins efficaces qu'un groupe de bêta-testeurs à très faible coût (ou gratuits) .

Le 4ème point me rappelle une de mes expériences. J'ai travaillé sur une société très maigre, orientée XP, et gérée par Scrum, où les tests unitaires étaient fortement recommandés. Cependant, dans son cheminement vers un style plus allégé et moins bureaucratique, la société a tout simplement négligé la construction d'une équipe d'assurance qualité - nous n'avions aucun testeur. Si souvent, les clients ont trouvé des bugs triviaux sur certains systèmes, même avec une couverture de test> 95%. J'ajouterais donc un autre point:

  • Les tests automatisés peuvent vous faire penser que le contrôle qualité et les tests ne sont pas importants.

De plus, je pensais ces jours-ci à la documentation et cogité une hypothèse qui pourrait être valable (dans une moindre mesure) pour tester deux. Je pensais simplement que le code évoluait si rapidement qu'il était assez difficile de créer une documentation qui suit une telle vitesse. Il est donc plus intéressant de perdre du temps à rendre le code lisible qu'à la rédaction d'une documentation lourde, facilement périmée. (Bien sûr, cela ne s'applique pas aux API, mais seulement à l'implémentation interne.) Le test souffre un peu du même problème: il est peut-être trop lent à écrire par rapport au code testé. OTOH, le problème est moins grave, car les tests vous avertissent qu’ils sont obsolètes. Votre documentation restera silencieuse tant que vous ne la relisez pas très attentivement .

Enfin, un problème que je trouve parfois: les tests automatisés peuvent dépendre d'outils, et ces outils peuvent être mal écrits. J'ai commencé un projet en utilisant XUL il y a quelque temps et, mec, c'est très pénible d'écrire des tests unitaires pour une telle plate-forme. J'ai lancé une autre application à l'aide d'Objective-C, Cocoa et Xcode 3 et le modèle de test utilisé consistait essentiellement en une série de solutions de contournement.

J'ai d'autres expériences sur les inconvénients des tests automatisés, mais la plupart d'entre elles sont énumérées dans d'autres réponses. Néanmoins, je suis un ardent défenseur des tests automatisés. Cela économise énormément de travail et de maux de tête et je le recommande toujours par défaut. J'estime que ces inconvénients ne sont que de simples détails par rapport aux avantages des tests automatisés. (Il est important de toujours proclamer votre foi après avoir commenté les hérésies pour éviter l'autodéfense.)

brandizzi
la source
3

Deux qui ne sont pas mentionnés sont:

  • Durée du temps nécessaire à l'exécution d'une grande suite de tests

J'ai participé aux efforts d'assurance qualité automatisés, où il m'a fallu une demi-journée pour exécuter les tests, car les tests étaient lents. Si vous ne faites pas attention à la rédaction de vos tests, votre suite de tests pourrait également fonctionner de cette façon. Cela ne semble pas être un gros problème tant que vous ne gérez plus ce temps: "Oh, je viens de commettre un correctif, mais il faudra 4 heures pour prouver la justesse".

  • Fragilité de certaines méthodes d'écriture de test

Certaines méthodes de test (telles que l'automatisation de l'interface utilisateur) semblent s'interrompre chaque fois que vous vous retournez. Cela est particulièrement pénible si votre script, par exemple, bloque le processus de test car il attend qu'un bouton apparaisse, mais le bouton a été renommé.

Ce sont deux choses sur lesquelles vous pouvez travailler, avec de bonnes pratiques de test: trouvez des moyens de garder votre suite de tests rapide (même si vous devez effectuer des astuces telles que la répartition des tests sur des machines / processeurs). De même, on peut prendre soin d'éviter les méthodes fragiles d'écriture de tests.

RyanWilcox
la source
2

Je veux ajouter un autre, un faux sentiment de sécurité.

Au-delà de très petits ensembles de problèmes bien définis, il n’est pas possible de créer des tests complets. Il se peut et il reste souvent des bogues dans notre logiciel que les tests automatisés ne testent tout simplement pas. Lorsque les tests automatisés sont réussis, nous supposons trop souvent qu’il n’ya pas de bogues dans le code.

Jim C
la source
0

Il est difficile de convaincre le management / venture capitalist

  • testautomation augmente les coûts initiaux.
  • testautomation augmente le temps de mise sur le marché.
  • l'avantage de testautomation vient au milieu et au logterm. La concurrence acharnée se concentre davantage sur les avantages à court terme.

voir Test basé sur le marché pour les détails.

k3b
la source
-1

L'un des principaux inconvénients peut être surmonté en utilisant des tests d'autoapprentissage. Dans cette situation, les résultats attendus sont tous stockés sous forme de données et peuvent être mis à jour avec un minimum de révision par l'utilisateur de la suite de tests en mode auto-apprentissage (affiche les différences entre l'ancien résultat attendu et le nouveau résultat réel - mise à jour attendue si vous appuyez sur y). Ce mode d'apprentissage de la suite de tests doit être utilisé avec prudence afin d'éviter tout comportement anormal.

Richard Kay
la source