Découvrez comment la solution Parasoft Continuous Quality permet de contrôler et de gérer les environnements de test pour fournir des logiciels de haute qualité en toute confiance. Inscrivez-vous pour la démo >>

BLOG

Vos tests unitaires échouent et vous ne savez pas pourquoi?

Vos tests unitaires échouent et vous ne savez pas pourquoi? Temps de lecture : 5 minutes
Parmi les nombreuses raisons pour lesquelles les développeurs de logiciels se plaignent des tests unitaires, la gestion des suites de tests bruyantes est l'une des plus importantes. Et plus un logiciel existe depuis longtemps, plus il devient bruyant.

Pour clarifier, par «bruit», je veux dire des tests qui échouent constamment, mais vous savez (pensez) que ça va de toute façon, alors laissez-les simplement faire. Ou des tests qui échouent parfois et fonctionnent parfois, mais personne n'a jamais pris la peine de les comprendre ou de les réparer. Et puis il y a des tests qui échouent légitimement parce que le code a changé et que le test doit être mis à jour. Tout ce bruit ne fait que crier à notre attention, mais le hic, c'est que plus il y a de bruit, moins nous sommes susceptibles de faire quoi que ce soit de significatif à ce sujet.

Mais devinez quoi? Quelque part dans ce bruit de tests «échoués mais OK», il y a de vrais problèmes que vous souhaiteriez connaître. Pensez-y comme si vous essayez d'utiliser un correcteur orthographique. Si vous ne le suivez pas, vous obtiendrez toutes sortes de choses qui ne vous intéressent pas, comme des mots, des noms, etc., qui ne sont pas de vrais problèmes d'orthographe. Mais les erreurs embarrassantes que vous avez réellement commises se cachent quelque part dans ce désordre - des mots mal orthographiés que vous voulez sortir de là. Et bien sûr, il y a des tonnes de fautes d'orthographe erronées à travers le monde - mais contrairement à votre logiciel, il n'y a pas beaucoup de risques inhérents, juste un peu d'embarras.

Et pourtant, les suites de tests unitaires sont généralement dans le même état. Beaucoup de résultats bruyants que nous nous habituons à voir et à ignorer, cachent malheureusement de vrais résultats que nous devons connaître et comprendre. Dans de nombreuses organisations, pour résoudre ce problème, quelqu'un planifie un sprint pour nettoyer la suite de tests de temps en temps, de quelques mois d'intervalle à même quelques années. On passe beaucoup de temps à rendre la suite aussi propre qu'humainement possible, mais le problème revient inévitablement - et plus rapidement que prévu. Cela crée une boucle de rétroaction négative - personne ne veut nettoyer les tests parce qu'ils pensent qu'ils seront à nouveau bruyants la prochaine fois.

La réponse est d'adopter une approche plus fonctionnelle - une approche qui supprime les sprints de nettoyage fastidieux et inutiles et évite les suites de tests bruyantes dès le début.

Minimiser les suites de tests bruyantes

Pour ce faire, il est important de comprendre ce que cela signifie lorsqu'un test unitaire échoue. Cela se résume à trois raisons, avec des correctifs simples:

  1. Le code est cassé. Alors, corrigez le code. (C'est idéalement ce que vous disent les suites de tests propres.)
  2. Le code a été modifié correctement et maintenant le test est interrompu. Alors, corrigez le test pour qu'il corresponde au nouveau code. (Si votre code change, vous pouvez vous attendre à ce que cela se produise. Une bonne raison de travailler sur des tests lorsque vous travaillez sur le code.)
  3. Le test est erroné et le code est correct. Alors, corrigez le test. (Ou peut-être le supprimer. Mais la clé est - n'ignorez pas le test.)

À présent. Vous pensez peut-être - et si une tonne de mes cas de test entraient dans cette troisième catégorie? En quoi cela peut-il aider? Alors décomposons cela.

Les raisons du bruit se résument généralement à quelques problèmes de base: de mauvais tests, des tests fragiles ou de mauvaises affirmations. Les mauvais tests sont des tests qui ne font pas correctement leur travail. Soit ils testent plus qu'ils ne le devraient, soit ils s'accrochent à des données incohérentes ou susceptibles de changer en fonction de conditions externes.

Pour minimiser le bruit, assurez-vous que pour chaque test qui vous pose problème (ou mieux encore tous vos tests), vous avez une bonne réponse à ces deux questions simples:

  1. Qu'est-ce que cela signifie si le test réussit?
  2. Qu'est-ce que cela signifie si le test échoue?

Si, pour un test, vous n'avez pas de réponse raisonnable à ces deux questions, il doit être amélioré.

Améliorer les tests fragiles

Les tests fragiles sont ceux qui sont faciles à casser. Encore une fois, c'est souvent un symptôme d'assertions paresseuses - le simple fait de vérifier les choses parce qu'elles peuvent être vérifiées ne signifie pas qu'elles doivent être vérifiées. Chaque assertion doit avoir une signification réelle en ce qui concerne l'exigence que remplit le code testé. Les coupables courants incluent les assertions sensibles à la date / heure, les dépendances du système d'exploitation, les dépendances de nom de fichier / chemin, les installations de logiciels tiers, les API partenaires, etc. Assurez-vous de n'affirmer que ce dont vous avez le moins besoin pour faire un bon test et assurez-vous que tout ce dont vous aurez besoin pour le test fait partie de votre système de contrôle de code source et de construction.

D'autres mauvaises affirmations sont celles qui sont soit constamment dans un état d'échec, mais cela ne vous dérange pas de les relâcher quand même ("Oh, ça va, ne vous en faites pas"), ou celles qui sont dans un état en constante évolution (" C'était bien avant, et hier c'était un échec, mais aujourd'hui ça va !! »). Si le code est en évolution, il peut être acceptable d'avoir des résultats en constante évolution pendant une courte période, mais à long terme, cela devrait être inacceptable. Vous devez comprendre pourquoi le résultat du test change tout le temps, ou certainement pourquoi vous pensez qu'il est normal d'échouer et de toujours publier. Faire un examen par les pairs de vos tests unitaires, y compris les assertions, contribuera grandement à résoudre ce problème de manière permanente. (Un avantage supplémentaire de l'examen par les pairs? Il est beaucoup plus facile de survivre si vous êtes dans un environnement de conformité où les tests font partie d'une surveillance obligatoire.)

L'évaluation des tests cassés est vraiment un excellent endroit pour effectuer la plupart de votre nettoyage. Je vous mets au défi de regarder attentivement les tests qui échouent depuis des mois, voire des années. Demandez-vous s'ils ajoutent vraiment de la valeur. Rappelez-vous, vous ignorez les résultats de toute façon, alors honnêtement à quoi servent-ils? La suppression des tests que vous ignorez vous permettra de vous concentrer sur les tests qui comptent et améliorera réellement votre qualité globale.

Et ainsi cela devient assez simple (bien que cela puisse prendre un investissement initial de temps). Pour nettoyer, observez simplement les meilleures pratiques suivantes:

  • Exécutez des tests régulièrement pour qu'ils ne soient pas obsolètes - travaillez dessus avec le code.
  • Supprimez les tests qui échouent toujours ou corrigez-les.
  • Supprimez les tests qui inversent constamment l'état (réussite / échec) ou renforcez-les.
  • Tests unitaires d'examen par les pairs.

Et bien sûr, n'oubliez pas d'utiliser l'automatisation pour faire le travail fastidieux afin que le temps que vous passez à écrire des tests soit plus productif, vous permettant de créer des tests moins bruyants.

Utilisation de l'automatisation des tests

Tirer parti des tests logiciels automatisés permet de rendre les tâches de test unitaire moins fastidieuses. Si vous pouvez laisser l'automatisation faire les parties simples et fastidieuses (dans lesquelles les ordinateurs sont bons), cela vous libère pour faire les choses qui nécessitent une réelle intelligence humaine (dans laquelle vous êtes doué). Par exemple, laissez l'automatisation créer la première passe de travail de votre xUnité cas de test (code simple qui devient très fastidieux à faire). Si vous laissez un outil générer automatiquement vos méthodes de test getter / setter, vous pouvez gagner beaucoup de temps que vous pouvez utiliser pour d'autres choses plus intéressantes.

Lorsque nous devenons plus sophistiqués avec l'automatisation des tests, les outils peuvent aider encore plus, en effectuant certaines des parties les plus délicates des tests unitaires, telles que la création et la configuration de stubs et de mocks. Plus vous tirerez parti de l'automatisation, moins les tests unitaires prendront de temps - et ce sera également beaucoup moins ennuyeux. Si vous utilisez Java, jetez un oeil à la Solution de tests unitaires Parasoft. Il fait toutes ces choses, et bien plus encore, ce qui rend les tests unitaires non seulement plus faciles, mais beaucoup plus agréables.

Automatisez la création de tests JUnit et commencez à aimer les tests unitaires

Écrit par

Arthur Hicken

Arthur est impliqué dans la sécurité logicielle et l'automatisation des tests chez Parasoft depuis plus de 25 ans, aidant à la recherche de nouvelles méthodes et techniques (dont 5 brevets) tout en aidant les clients à améliorer leurs pratiques logicielles.

Recevez les dernières nouvelles et ressources sur les tests de logiciels dans votre boîte de réception.