Qu'est-ce que la couverture du code ?
Dans cet article, vous découvrirez comment vous lancer avec la couverture de code, trouver le bon outil et comment calculer votre couverture.
Sten Pittet
Auteur collaborateur
La couverture de code est une métrique qui peut vous permettre de comprendre la part testée de votre source. Cette métrique est très utile, car elle peut vous aider à évaluer la qualité de votre suite de tests. Nous découvrirons ici de quelle manière vous pouvez vous lancer avec vos projets.
Comment la couverture de code est-elle calculée ?
Les outils de couverture de code utiliseront un ou plusieurs critères pour déterminer comment votre code a été mis à l'épreuve ou non pendant l'exécution de votre suite de tests. Les métriques courantes qui seront probablement mentionnées dans vos rapports de couverture sont les suivantes :
- Couverture des fonctions : nombre de fonctions définies ayant été appelées.
- Couverture des instructions : combien d'instructions du programme ont été exécutées.
- Couverture des branches : combien de branches des structures de contrôle (les instructions « If » par exemple) ont été exécutées.
- Couverture des conditions : combien de sous-expressions booléennes ont été testées pour une valeur vraie et fausse (true/false).
- Couverture des lignes : combien de lignes du code source ont été testées.
Ces indicateurs sont généralement représentés par le nombre d'éléments réellement testés, les éléments détectés dans votre code et un pourcentage de couverture (éléments testés/éléments détectés).
Ces métriques sont liées, mais distinctes. Dans le script simple ci-dessous, une fonction JavaScript vérifie si une requête est un multiple de 10. Nous utiliserons cette fonction plus tard pour vérifier si 100 est ou n'est pas multiple de 10. Cela nous permettra de comprendre la différence entre la couverture des fonctions et la couverture des branches.
Découvrir la solution
Développez et exploitez des logiciels grâce à Open DevOps
Matériel connexe
Tests automatisés pour DevOps
coverage-tutorial.js
function isMultipleOf10(x) { if (x % 10 == 0) return true; else return false; } console.log(isMultipleOf10(100));
Nous pouvons utiliser l'outil de couverture istanbul pour voir quelle quantité de notre code est exécutée lors du lancement de ce script. Après avoir exécuté l'outil de couverture, nous obtenons un rapport de couverture présentant nos métriques de couverture. Nous pouvons constater que même si notre couverture des fonctions est de 100 %, notre couverture des branches n'est que de 50 %. Nous pouvons également remarquer que l'outil de couverture de code istanbul ne calcule pas une métrique de couverture des conditions.
C'est parce que, lorsque nous exécutons notre script, l'instruction « Else » (différent) n'a pas été lancée. Si nous voulions obtenir une couverture de 100 %, nous pourrions simplement ajouter une autre ligne, essentiellement un autre test, pour nous assurer que toutes les branches de l'instruction « If » (Si) sont utilisées.
coverage-tutorial.js
function isMultipleOf10(x) { if (x % 10 == 0) return true; else return false; } console.log(isMultipleOf10(100)); console.log(isMultipleOf10(34)); // This will make our code execute the "return false;" statement.
Une deuxième exécution de notre outil de couverture montrera maintenant que 100 % de la source est couverte grâce à nos deux instructions « console.log() » en bas.
Dans cet exemple, nous avons simplement enregistré les résultats dans le terminal, mais le même principe s'applique lorsque vous exécutez votre suite de tests. Votre outil de couverture de code surveillera l'exécution de votre suite de tests et vous indiquera combien d'instructions, de branches, de fonctions et de lignes ont été exécutées dans le cadre de vos tests.
Couverture de code : 6 conseils pour vous lancer
1. Trouvez le bon outil pour votre projet
Vous trouverez peut-être plusieurs options pour créer des rapports de couverture en fonction des langages que vous utilisez. Certains des outils populaires sont énumérés ci-dessous :
- Java : Atlassian Clover, Cobertura, JaCoCo
- Javascript : istanbul
- PHP : PHPUnit
- Python : Coverage.py
- Ruby : SimpleCov
Une comparaison d'outils peut également vous aider à prendre votre décision. Certains outils tels qu'istanbul afficheront les résultats directement dans votre terminal tandis que d'autres outils peuvent générer un rapport HTML complet qui vous permet d'explorer quelle partie du code n'est pas suffisamment couverte.
2. Quel pourcentage de couverture devez-vous viser ?
En matière de couverture de code, il n'y a pas de solution magique. Un pourcentage élevé de couverture pourrait encore poser problème si des parties essentielles de l'app ne sont pas testées, ou si les tests existants ne sont pas suffisamment robustes pour capturer les défaillances à l'avance. Cela dit, il est généralement admis qu'une couverture de 80 % est un bon objectif à atteindre. Essayer d'atteindre une couverture plus élevée peut s'avérer coûteux, tout en n'offrant pas nécessairement assez d'avantages.
Lors de la première exécution de votre outil de couverture, vous pourriez constater que votre pourcentage de couverture est assez faible. Si vous vous lancez dans les tests, c'est une situation normale et vous ne devez pas vous sentir obligé d'atteindre une couverture de 80 % tout de suite. En effet, en se précipitant sur un objectif de couverture, votre équipe pourrait être amenée à écrire des tests qui concernent chaque ligne du code au lieu d'écrire des tests basés sur les exigences métier de votre app.
Par exemple, dans le cas ci-dessus, nous avons atteint une couverture de 100 % en testant si 100 et 34 étaient des multiples de 10. Et si nous nommions notre fonction à l'aide d'une lettre au lieu d'un nombre ? Devrions-nous obtenir un résultat vrai/faux ? Ou une exception ? Il est important que vous donniez le temps à votre équipe de penser aux tests du point de vue de l'utilisateur et pas seulement en examinant les lignes de code. La couverture de code ne vous indiquera pas si vous manquez des éléments dans votre source.
3. Concentrez-vous d'abord sur les tests unitaires
Les tests unitaires consistent à s'assurer que les méthodes individuelles des classes et composants utilisées par votre app fonctionnent. Ils sont généralement peu coûteux à implémenter et rapides à exécuter, et ils vous donnent l'assurance générale que la base de la plateforme est solide. Un moyen simple d'augmenter rapidement votre couverture de code consiste à commencer par ajouter des tests unitaires car, par définition, ils devraient vous aider à vous assurer que votre suite de tests s'applique à toutes les lignes de code.
4. Utilisez les rapports de couverture pour identifier les oublis critiques lors des tests
Bientôt, vous aurez tellement de tests dans votre code qu'il vous sera impossible de savoir quelle partie de l'app est vérifiée pendant l'exécution de votre suite de tests. Vous saurez ce qui est défectueux lorsque vous obtiendrez un build non fonctionnel, mais il vous sera difficile de comprendre quels composants ont été testés.
C'est là que les rapports de couverture peuvent fournir des conseils pratiques à votre équipe. La plupart des outils vous permettront de creuser dans les rapports de couverture pour voir les éléments réels qui n'ont pas été couverts par les tests, puis de les utiliser pour identifier les parties critiques de votre app qui doivent encore être testées.
5. Intégrez la couverture de code à votre flux d'intégration continue lorsque vous êtes prêt
Une fois votre workflow d'intégration continue (CI) établi, vous pouvez commencer à faire échouer les tests si vous n'atteignez pas un pourcentage de couverture suffisamment élevé. Bien sûr, comme nous l'avons dit précédemment, il ne serait pas raisonnable de fixer un seuil d'échec trop élevé, et une couverture de 90 % est susceptible de faire échouer votre build dans de nombreux cas. Si votre objectif est une couverture de 80 %, vous devriez envisager un seuil d'échec à 70 % comme filet de sécurité pour votre culture CI.
Une fois encore, veillez à ne pas faire passer le mauvais message, car le fait de mettre votre équipe sous pression afin qu'elle atteigne une bonne couverture pourrait conduire à de mauvaises pratiques de test.
6. Une bonne couverture n'est pas synonyme de bons tests
Pour instaurer une bonne culture de test, il faut d'abord que votre équipe comprenne comment l'app est censée se comporter lorsqu'une personne l'utilise correctement, mais aussi lorsque quelqu'un essaie de l'endommager. Les outils de couverture de code peuvent vous permettre de comprendre où votre attention doit ensuite se porter, mais ils ne vous diront pas si vos tests existants sont suffisamment robustes pour les comportements inattendus.
L'obtention d'une grande couverture est un excellent objectif, mais elle doit être associée à une suite de tests robuste, capable de garantir que les classes individuelles ne sont pas endommagées et de vérifier l'intégrité du système.
Découvrez-en plus sur les différents types de tests logiciels. Atlassian Open DevOps fournit une plateforme de chaîne d'outils ouverte qui vous permet de créer un pipeline de développement de CD avec les outils que vous aimez. Découvrez comment Atlassian et des outils tiers peuvent intégrer les tests à votre workflow grâce à nos tutoriels de tests DevOps.
Partager cet article
Thème suivant
Lectures recommandées
Ajoutez ces ressources à vos favoris pour en savoir plus sur les types d'équipes DevOps, ou pour les mises à jour continues de DevOps chez Atlassian.
Communauté DevOps
Lire le blog
