Mesure de la couverture des tests unitaires dans les projets Android multi-modules utilisant Jacoco: Partie 2
Dans le premier article, nous avons découvert l’une des deux commandes Gradle clés fournies avec le plugin Jacoco – jacocoTestReport. Comme vous le savez maintenant, il peut être utilisé pour mesurer la couverture de code dans votre projet en générant des rapports détaillés aux formats HTML, XML ou CVS. Cette fois, je voudrais partager mon expérience avec la deuxième pièce de ce puzzle – jacocoTestCoverageVerification.
Selon la documentation, cette tâche effectue les opérations suivantes:
Tâche de vérification des mesures de couverture de code. Échoue la tâche si des violations sont détectées en fonction des règles spécifiées.
Donc, comme vous l’avez peut-être déjà deviné, cet outil peut être utilisé pour vérifier si un certain seuil de couverture est atteint ou non. Fondamentalement, vous spécifiez la couverture minimale mesurée en% et exécutez la tâche. Si votre unité teste la «visite» du% souhaité de votre base de code, cette tâche se terminera silencieusement. Sinon, cela échouera. Cela peut être très utile pour les équipes de développement car cela vous permet d’avoir une sorte d’application pour l’écriture de tests unitaires et tout ce que vous avez à faire pour cela est de configurer Jacoco et de simplement demander à votre CI / CD de s’exécuter jacocoTestCoverageVerification ainsi que d’autres tâches pour vos pipelines.
Commençons par la configuration. Je vais reprendre là où nous nous sommes arrêtés dans l’article précédent. Comme avec jacocoTestReport, il serait toujours utile d’avoir deux configurations différentes pour les modules Java / Kotlin et Android. Ajoutons deux fonctions supplémentaires à la jacoco.gradle fichier.
Chacune de ces fonctions enregistre jacocoTestCoverageVerification Tâche Gradle pour un module donné. Cette tâche est dérivée de la JacocoCoverageVerification type et dépend de testDebugUnitTest ce qui signifie que le lancement de la tâche de vérification exécutera également vos tests unitaires avant de faire la validation (ce qui est tout à fait prévisible: nous devons exécuter tous les tests avant de pouvoir mesurer leur couverture). Ces fonctions ont également threshold afin que nous puissions le fournir dynamiquement du côté appelant.
Il est temps de se rappeler que nous parlons de la configuration Gradle multi-modules, donc coder en dur un seuil de couverture unique peut ne pas être une très bonne idée: de nombreux modules voudront probablement personnaliser cette valeur par eux-mêmes en fonction du type de module, stade de développement, etc. Le moyen le plus simple d’y parvenir est de définir des constantes avec un nom fixe au niveau du module build.gradle fichiers puis lisez sa valeur lors de la configuration de Jacoco:
Module A build.gradle:
Module B build.gradle:
Et revenons à notre jacoco.gradle:
Notez que jacocoTestCoverageThresholdDefault La valeur sera utilisée si certains modules ne veulent pas fournir de seuil personnalisé et acceptent les valeurs par défaut au niveau du projet. Où cette valeur par défaut peut-elle être stockée? Allumons lejacoco-ignore-list.gradle de l’article précédent en convertissant en un plus global jacoco-config.gradle:
Nous avons terminé la configuration de base: tous les modules prennent désormais en charge jacocoTestCoverageVerification tâche. Comme avec jacocoTestReport, il peut être lancé pour des modules individuels en exécutant la commande suivante
Nom du module ./gradlew: jacocoTestCoverageVerification
Ou vous pouvez vérifier tous les modules à la fois en tapant
./gradlew jacocoTestCoverageVerification
Maintenant, vous pouvez trouver rapidement des modules sans tests et blâmer leurs auteurs, non? Pas encore, mais nous sommes proches! 🙂 Il est apparu que Jacoco et ses deux tâches ignorent les modules auxquels aucun test n’a été ajouté, c’est-à-dire jacocoTestCoverageVerification n’échouera pas avec l’erreur « 0% de couverture de test » pour ces modules pour une raison quelconque, il échouera uniquement si ce module contient au moins 1 test unitaire et que ce test ne fournit pas la couverture de code souhaitée. Ajoutons une solution de contournement personnalisée à cette limitation.
Tout d’abord, créez une nouvelle tâche à l’intérieur jacoco.gradle :
Cette tâche s’assurera simplement que chaque module contient des dossiers de test non vides (soit test ou androdiTes). Cette logique peut être étendue si nécessaire, mais j’ai décidé de ne pas être trop paranoïaque à ce sujet. Maintenant, nous devons lier cette nouvelle création testExistenceValidation à la tâche de vérification. Comme vous le savez déjà, cela peut être réalisé en utilisantdependsOn:
Terminé! Notre tâche de vérification dépend désormais testExistenceValidation routine et il l’exécutera automatiquement avant de faire son travail principal.
P.S .: les versions complètes de tous les fichiers source que j’ai mentionnés ici se trouvent dans ce Gist.
