Couverture de code par les tests en Swift : comment mesurer et améliorer la qualité

Couverture de code par les tests en Swift : des « simples tests » à la confiance réelle

Avez-vous déjà supprimé du code « mort » pour voir la compilation échouer une semaine plus tard ? Ou vous êtes-vous vanté d'une couverture à 90% alors que des bugs surgissaient encore en production ? Si oui, cet article est pour vous. La couverture de code par les tests (code coverage) en Swift n'est pas simplement une case à cocher pour le CI/CD. C'est votre radar personnel : il montre quelles parties du code sont réellement testées et lesquelles vivent « sur la bonne foi ».

Nous n'allons pas vous dire qu'il faut écrire des tests — c'est une évidence. À la place, nous allons voir : comment faire en sorte que Xcode calcule correctement la couverture, quelles métriques sont réellement importantes (spoiler : pas seulement le pourcentage), et pourquoi une couverture à 100% est souvent un piège. C'est parti !

1. Pourquoi mesurer la couverture de code en Swift ?

Imaginez que vous êtes le capitaine d'un navire et que les tests sont vos navigateurs. La couverture de code est une carte sur laquelle sont marquées les zones « explorées ». Si la carte est blanche, vous naviguez à l'aveugle. Si elle est remplie à 100% mais sans tenir compte des cas limites, vous risquez quand même de vous échouer.

Les principales raisons d'adopter le code coverage Swift :

• Recherche des « zones grises » — vous voyez immédiatement quel code n'est jamais exécuté dans les tests (par exemple, les gestionnaires d'erreurs).
• Refactorisation sans crainte — une métrique de couverture élevée donne le feu vert pour réécrire des modules.
• Documentation des exigences — les tests deviennent une documentation vivante, et la couverture montre à quel point cette documentation est complète.
• Contrôle qualité dans le CI — vous pouvez interdire la fusion si la couverture tombe en dessous d'un seuil (par exemple, 80%).

Mais retenez l'essentiel : la couverture de code par les tests en Swift est une métrique, pas un objectif. Courir après un chiffre pour le chiffre même mène à des tests inutiles qui vérifient les getters et les setters.

2. Outils pour mesurer la couverture en Swift : de Xcode aux utilitaires tiers

L'écosystème Swift propose plusieurs façons d'obtenir les précieux pourcentages. Examinons les trois principales : Xcode intégré, l'utilitaire slather et les services CI (par exemple, Codecov).

2.1. Xcode Code Coverage intégré

L'outil le plus simple et le plus accessible. Tout ce dont vous avez besoin est d'activer l'option Gather coverage data dans le schéma de build (Product → Scheme → Edit Scheme → Test → Options). Après avoir exécuté les tests, ouvrez le Report Navigator (Cmd+9) et sélectionnez l'onglet Coverage.

Avantages : ne nécessite pas d'installation, intégration avec Xcode, affiche la couverture en temps réel.

Inconvénients : ne peut pas fusionner les résultats de plusieurs cibles, difficile à exporter dans le CI.

Exemple de configuration pour un projet :

// Dans le schéma de build (Test → Options), cochez "Code Coverage"// Après avoir lancé les tests (Cmd+U), consultez le rapport dans le Report Navigator.// Pour chaque fichier, vous voyez une ligne avec le pourcentage de couverture et les lignes surlignées :// vertes — exécutées, rouges — non exécutées.

2.2. Slather — un générateur de rapports flexible

Slather est un utilitaire open-source qui analyse les fichiers .profdata (résultats de couverture de Xcode) et génère de beaux rapports HTML, XML (Cobertura) ou même JSON. Il est particulièrement utile si vous utilisez un CI et souhaitez conserver l'historique de la couverture.

Installation via CocoaPods ou Homebrew :

# Homebrewbrew install slather

# CocoaPods (dans le Podfile)pod 'slather'

Exemple de configuration .slather.yml :

# .slather.ymlcoverage_service: cobertura_xmlxcodeproj: MyApp.xcodeprojscheme: MyAppsource_directory: MyApp/Sourcesoutput_directory: reportsignore:  - MyAppTests/*  - Pods/*

Lancement :

slather coverage -s --scheme MyApp MyApp.xcodeproj

Avantages : flexibilité, support de différents formats, intégration avec le CI.

Inconvénients :