Les deux grands pièges de la couverture du code

Vous ne voulez pas de couverture pour des raisons de couverture. Vous avez besoin d'une couverture significative qui indique que vous avez bien testé le logiciel.

Mesure de la couverture du code est l'une de ces choses qui attire toujours mon attention. D'une part, je constate souvent que les organisations ne savent pas nécessairement quelle quantité de code elles couvrent lors des tests – ce qui est vraiment surprenant ! À l'autre extrémité du spectre de couverture, il y a des organisations pour lesquelles le nombre est si important que la qualité et l'efficacité des tests sont devenues pour la plupart hors de propos. Ils chassent sans réfléchir le dragon à 100% et croient que s'ils ont ce numéro, le logiciel est bon, ou même le meilleur qu'il puisse être. C'est au moins aussi dangereux que de ne pas savoir ce que vous avez testé, en fait peut-être plus car cela peut vous donner un faux sentiment de sécurité.

La couverture de code peut être un bon nombre intéressant pour évaluer la qualité de votre logiciel, mais il est important de se rappeler qu'il s'agit d'un moyen plutôt que d'une fin. Nous ne voulons pas de couverture pour des raisons de couverture, nous voulons une couverture parce que c'est supposé pour indiquer que nous avons fait du bon travail en testant le logiciel. Si les tests eux-mêmes ne sont pas significatifs, alors en avoir plus n'indique certainement pas un meilleur logiciel. L'objectif important est de s'assurer que chaque morceau de code est testé, pas seulement exécuté. Faute de temps et d'argent pour tout tester complètement, assurez-vous au moins que tout ce qui est important est testé.

Cela signifie que si une faible couverture signifie que nous ne testons probablement pas suffisamment, une couverture élevée en soi ne correspond pas nécessairement à une qualité élevée - l'image est plus compliquée que cela.

De toute évidence, avoir un juste milieu où vous avez «suffisamment» de couverture pour être à l'aise pour publier le logiciel avec une bonne suite de tests stable et maintenable qui a «juste assez de tests» serait parfait. Mais encore, ces pièges de couverture sont courants.

Piège n° 1 : « Nous ne connaissons pas notre couverture »

Ne pas connaître votre couverture me semble déraisonnable - les outils de couverture sont bon marché et abondants. Un de mes amis suggère que les organisations savent que leur numéro de couverture n'est pas bon, donc les développeurs et les testeurs hésitent à exposer la mauvaise couverture à la direction. J'espère que ce n'est pas le cas habituel.

Un vrai problème que rencontrent les équipes en essayant de mesurer la couverture est que le système est trop compliqué. Lorsque vous créez une application à partir de morceaux sur des morceaux sur des morceaux, savoir simplement où placer les compteurs de couverture peut être une tâche ardue. Je suggérerais que s'il est réellement difficile de mesurer la couverture dans votre application, vous devriez réfléchir à deux fois à l'architecture.

Une deuxième façon de tomber dans ce piège se produit avec les organisations qui peuvent avoir beaucoup de tests, mais pas de numéro de couverture réel car elles n'ont pas trouvé de moyen approprié d'agréger les nombres de différentes exécutions de tests. Si vous effectuez des tests manuels, des tests fonctionnels, des tests unitaires et des tests de bout en bout, vous ne pouvez pas simplement additionner les chiffres. Même s'ils atteignent chacun une couverture de 25%, il est peu probable que ce soit 100% lorsqu'ils sont combinés. En fait, il est plus probable qu'il soit plus proche des 25% que des 100% lorsque vous l'examinez.

En fait, il existe en fait un moyen de mesurer et d'ajouter une couverture ensemble de manière significative. Chez Parasoft, nous exploitons la grande quantité de données granulaires capturées par nos rapports et notre outil d'analyse, PAO Parasoft, que nous pouvons utiliser dans ce contexte pour fournir une vue globale et agrégée de la couverture du code. Nos moniteurs d'application sont en mesure de collecter des données de couverture à partir de l'application directement pendant son test, puis d'envoyer ces informations à Parasoft DTP, qui regroupe les données de couverture pour toutes les pratiques de test, ainsi que pour les équipes de test et les exécutions de test.

Si cela ressemble à une quantité d'informations assez importante, vous avez raison! DTP fournit un tableau de bord interactif pour vous aider à naviguer dans ces données et à prendre des décisions sur où concentrer les efforts de test. Voir l'exemple de tableau de bord ci-dessous:

Si plusieurs tests ont couvert le même code, il ne sera pas surestimé, tandis que les parties non testées du code sont rapides et faciles à voir. Cela vous montre quelles parties de l'application ont été bien testées et celles qui ne l'ont pas été. Vous pouvez tout lire à ce sujet dans un livre blanc gratuit.

Donc, plus d'excuses pour ne pas mesurer la couverture.

Piège n° 2 : « La couverture, c'est tout ! »

Il est courant de penser à tort que la couverture est primordiale. Une fois que les équipes sont en mesure de mesurer la couverture, il n'est pas rare que les responsables disent "augmentons ce nombre". Finalement, le nombre lui-même devient plus important que les tests. La meilleure analogie est peut-être celle que j'ai entendue du fondateur de Parasoft, Adam Kolawa :

«C'est comme demander à un pianiste de couvrir 100% des touches du piano plutôt que d'appuyer uniquement sur les touches qui ont du sens dans le contexte d'un morceau de musique donné. Quand il joue le morceau, il obtient le niveau de couverture clé qui lui convient. »

C'est là que réside le problème - une couverture stupide est la même chose qu'une musique stupide. La couverture doit refléter une utilisation réelle et significative du code, sinon ce n'est que du bruit.

Et en parlant de bruit… le coût de la couverture augmente à mesure que la couverture augmente. N'oubliez pas que vous devez non seulement créer des tests, mais aussi les maintenir à jour. Si vous ne prévoyez pas de réutiliser et de maintenir un test, vous ne devriez probablement pas perdre de temps à le créer en premier lieu. Au fur et à mesure que la suite de tests s'agrandit, le nombre de bruits augmente de manière inattendue. Deux fois plus de tests peuvent signifier deux ou même trois fois plus de bruit. Les tests sans signification finissent par créer plus de bruit que les bons tests car ils n'ont pas de contexte réel, mais doivent être traités à chaque fois que les tests sont exécutés. Parlez de dette technique ! Les tests inutiles sont un réel danger.

Désormais, dans certaines industries, les industries critiques pour la sécurité par exemple, la mesure de couverture à 100% est une exigence. Mais même dans ce cas, il est trop facile de traiter toute exécution d'une ligne de code comme un test significatif, ce qui n'est tout simplement pas vrai. J'ai deux questions de base que je pose pour déterminer si un test est un bon test:

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

Idéalement, lorsqu'un test échoue, nous savons quelque chose sur ce qui n'a pas fonctionné, et si le test est vraiment bon, il nous orientera dans la bonne direction pour y remédier. Trop souvent, lorsqu'un test échoue, personne ne sait pourquoi, personne ne peut le reproduire et le test est ignoré. À l'inverse, lorsqu'un test réussit, nous devrions être en mesure de savoir ce qui a été testé - cela devrait signifier qu'une fonctionnalité ou un élément de fonctionnalité particulier fonctionne correctement.

Si vous ne pouvez pas répondre à l'une de ces questions, vous avez probablement un problème avec votre test. Si vous ne pouvez répondre à aucune d'elles, le test pose probablement plus de problèmes qu'il n'en vaut la peine.

Le moyen de sortir de ce piège est d'abord de comprendre que le pourcentage de couverture lui-même n'est pas l'objectif. Le véritable objectif est de créer des tests utiles et significatifs. Cela prend bien sûr du temps. En code simple écriture de tests unitaires est simple, mais dans les applications complexes du monde réel, cela signifie écrire des stubs et des mocks et utiliser des frameworks. Cela peut prendre un peu de temps et si vous ne le faites pas tout le temps, il est facile d'oublier les nuances des API impliquées. Même si vous êtes sérieux au sujet des tests, le temps nécessaire pour créer un très bon test peut être plus long que prévu.

Nous avons en fait une nouvelle technologie pour cela chez Parasoft, qui se trouve à l'intérieur Jtest Parasoft, notre outil de test de développement Java. L'assistant de test unitaire prend en charge les tâches fastidieuses consistant à corriger les simulations et les talons. Il peut également aider à étendre les tests existants de manière utile pour augmenter la couverture - en vous aidant à créer de bons tests unitaires et à faire des recommandations pour améliorer la couverture et la qualité des tests.

J'espère que vous avez appris que la couverture est importante et que l'amélioration de la couverture est un objectif louable. Mais gardez à l'esprit que la simple poursuite du pourcentage n'est pas aussi précieuse que l'écriture de tests stables, maintenables et significatifs.

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.