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

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.

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.

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é.

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.

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.

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.

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.

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.)

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.

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.

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.

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.