Publié par
Il y a 2 années · 6 minutes · iOS, Mobile

Exploitons la couverture de code en Swift

Apple_Swift_LogoUne des annonces de la WWDC 2015 qui nous a le plus surpris intéressés a été, sans doute, le support de métriques de couverture de code en Swift. Dans cet article nous tâcherons de comprendre les différences de fonctionnalités par rapport au passé et comment intégrer ce KPI dans notre travail quotidien.

Cet article est la version texte de notre talk « Leveraging Xcode Code Coverage”, présentée lundi dernier à la conférence Mobile Optimized à Minsk, dont les slides sont disponibles ici.

La couverture de code est une métrique qui mesure la valeur de nos tests et permet d’identifier quel code est exécuté quand nos tests tournent mais, surtout, quelles portions de code ne sont pas testées.

Comment ça marche ?

La production des informations de couverture de code se fait en deux temps :

  1. Au compile time, le compilateur prépare les fichiers à l’analyse
  2. Au runtime, les lignes de code touchées par les tests sont annotées dans un fichier spécifique

La couverture de code avant juin 2015

Avant la WWDC 2015, seule la couverture de code de Objective-C était prise en charge par les outils d’Apple, tandis que celle de Swift n’était pas supporté. Également, le support de Objective-C était parfois inconsistant et nécessitait quelques astuces pour obtenir l’information voulue.

Comment ça marche ?

La procédure nécessaire afin de construire la couverture de code pour Objective-C était une variante de celle imposée par gcov, introduite par gcc : deux réglages devaient être ajoutés aux Build Settings :

  1. “Generate test coverage files”, qui correspond au flag gcc « -ftest-coverage »
  2. « Instrument program flow”, qui correspond au flag « -fprofile-arcs”

Le premier de ces deux flag permet la création des files “.gcno”, qui contiennent les informations nécessaires pour construire le graphe d’exécution et assigner le nombre de lignes.

Quant au deuxième, “Instrument program flow”, il correspond à la création des fichiers “.gcda” qui contient le nombre de transitions sur les différents arcs du graphe et autres informations d’ensemble.

Afin de forcer la génération de ces données en ligne de commande, il était possible d’utiliser la commande suivante :

GCC_INSTRUMENT_PROGRAM_FLOW_ARCS=YES
 GCC_GENERATE_TEST_COVERAGE_FILES=YES
 xcodebuild [...] 
 test

Exploitation des données

Un bon nombre d’outils permettent de lire et exporter les rapports mais, en particulier, nous utilisions les suivants :

  • Coverstory, un outil GUI pour lire les fichiers “.gcda » et « .gcno”
  • gcovr, qui permet de traduire ces fichiers en format Cobertura XML
  • lcov, qui génère un rapport visuel sous forme de HTML navigable
  • et, surtout, Slather.

Slather

Slather, développé par la société américaine Venmo, exporte les données de couverture de code sous différents formats, y compris Gutter JSON, Cobertura XML, HTML et texte. De plus, il s’intègre facilement avec les outils de build automatique, tels que Jenkins, bien sûr, mais aussi Travis CI et coveralls.

Aussi, un des atouts majeurs de Slather est sa facilité de configuration et d’intégration à l’intérieur d’un système d’intégration continue. Slather est Open Source, et disponible ici : http://github.com/venmo/Slather.

Swiftcov

Realm, la société américaine qui développe la base de données homonyme, a aussi développé un système qui permet de calculer les informations de couverture du code Swift, appelé Swiftcov. Swiftcov, dont le répo GitHub est accessible ici, se sert des breakpoints LLDB pour détecter quelles lignes ont été touchées par l’exécution de nos tests.

La couverture de code après juin 2015

Au cours de la keynote de la WWDC 2015, Apple a annoncé le support de la couverture de code pour le langage Swift.

Comment ça marche ?

gcov, maintenant devenu legacy, a été remplacé par un nouveau format de données, appelé profdata.

Malgré ce que Apple a fait comprendre, ce dernier format est censé remplacer complètement gcov car, depuis la toute première beta de Xcode 7, il prend en charge Swift aussi bien que le “vieux” Objective-C.

Afin d’activer le réglage, à partir de Xcode 7, il faut accéder aux paramètres du “scheme” et, dans le tab “Test”, il est nécessaire de cocher la case “Gather coverage data”.
collect_coverage_annotated

Quant à la ligne de commande, xcodebuild s’est enrichi d’un nouveau paramètre, “-enableCodeCoverage”. Un exemple d’usage est le suivant :

xcodebuild
 -scheme MoDevByProject
 -destination "name=iPhone 6,OS=latest"
 -enableCodeCoverage YES
 test

Une fois les tests exécutés, l’information de couverture est disponible directement dans Xcode, à côté de notre code source (cf image ci-dessous) et aussi dans le “Report Navigator” où nous pouvons aussi visualiser dans le détail quelles méthodes sont couvertes par nos tests.
swift-xebia
swift-xebia-blog

Exploitation des données

Non seulement Apple a intégré ces données visuellement dans Xcode mais la société de Cupertino a aussi ajouté des nouvelles fonctionnalités à l’outil en ligne de command llvm-cov, qui permet de travailler avec le format .profdata.

La commande llvm-cov show, permet notamment d’exporter en format texte les informations de couverture ; aussi, cette commande produit en tant qu’output les fichiers code source annotés, ce qui permet de lire et processer facilement le contenu.

Slather (returns)

À travers une récente Pull Request, le projet Slather permet de manipuler les fichiers profdata en les convertissant vers d’autres formats et en les intégrant à l’intérieur des autres plateformes supportées par l’outil.

Xcode Server

Si vous souhaitez refondre (ou mettre en place pour la première fois) votre usine logicielle, il est peut-être temps de commencer à prendre en consideration Xcode Server, qui est partie de la solution (gratuite) OS X Server, distribuée par Apple.

En effet, à l’aide de la nouvelle version des bots Xcode et de Xcode Server, il est maintenant possible de prendre en charge les valeurs de couverture de code et, aussi, d’afficher ces résultats à l’intérieur d’un navigateur dans l’efficace présentation “Big Screen”.

Pour ce faire, il faut suivre les étapes suivantes :

  1. Installer OS X server
  2. Activer les services “Xcode” et “Websites” (les configurations par défaut sont souvent suffisantes)
  3. Créer un nouveau projet sous contrôle d’un SCM tel que git
  4. Dans Xcode, créer un Xcode bot sous “Product > Create Bot”
  5. Choisir la fréquence d’intégration et activer la couverture de code (cf image ci-dessous) à coté du libellé “Code Coverage”.
  6. Lancer une intégration
  7. Accéder, à travers le navigateur Web, au host indiqué par votre instance de Mac OS.

bot_coverage

Conclusion

La couverture de code est très utile pour vérifier la santé de votre base de code. Même si elle ne peut pas remplacer la confiance envers un code bien écrit et bien architecturé, cette métrique peut vous aider à écrire du code de meilleure qualité en vous encourageant à vous donner des objectifs concrets au jour le jour.

Aussi, et finalement, les nouveaux outils proposés par Apple vous permettent désormais de garder sous contrôle ces valeurs en quelques minutes, avec une configuration simple et immédiate.

Une réflexion au sujet de « Exploitons la couverture de code en Swift »

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *