Couverture de code par les tests en Rust : de zéro à la confiance

Pourquoi la couverture de code n'est pas qu'une simple case à cocher dans le CI/CD ?

Imaginez : vous avez écrit en Rust un module pour analyser des fichiers de configuration complexes. Le compilateur est content, les tests passent, mais un mois plus tard, la production plante avec une erreur sur un cas limite rare. Cela vous dit quelque chose ? C'est ici qu'entre en scène la couverture de code par les tests en Rust — une métrique qui montre quel pourcentage de votre code est réellement exécuté pendant les tests.

Mais soyons honnêtes : la course aux 100% de couverture est un piège. Il est bien plus important de comprendre quelles lignes restent sans tests et pourquoi. Dans cet article, nous allons analyser trois outils principaux pour Rust : tarpaulin, grcov et la boîte à outils LLVM intégrée. Vous apprendrez à transformer des pourcentages bruts en informations exploitables pour le refactoring.

Pourquoi un développeur Rust devrait-il surveiller la couverture ?

Rust est réputé pour sa sécurité mémoire, mais cela n'élimine pas les erreurs logiques. La couverture de code par les tests aide à :

\n
• Détecter le « code mort » — des fonctions ou branches qui ne sont jamais appelées.
\n
• Augmenter la confiance lors du refactoring — en sachant que les chemins critiques sont couverts par les tests.
\n
• Améliorer la documentation — les tests servent souvent de meilleure documentation s'ils couvrent tous les scénarios.
\n

La métrique principale est la line coverage (couverture de lignes), mais nous examinerons aussi la branch coverage (couverture de branches), particulièrement importante en Rust en raison de l'abondance d'expressions match.

Outil n°1 : cargo-tarpaulin — simplicité et rapidité

tarpaulin est l'outil le plus populaire pour la couverture de code en Rust. Il fonctionne « prêt à l'emploi » et ne nécessite pas de configuration complexe. Installation :

cargo install cargo-tarpaulin

Lancement de l'analyse de base :

cargo tarpaulin --out Html

Cette commande générera un rapport HTML dans le dossier tarpaulin-report.html. Ouvrons-le — et nous verrons une carte colorée de votre projet : lignes vertes (couvertes par les tests), rouges (non couvertes) et grises (non exécutables, par exemple les commentaires).

Exemple : testons une fonction simple

Créons un fichier src/lib.rs avec une fonction de calcul de factorielle :

pub fn factorial(n: u32) -> u32 {\n    match n {\n        0 | 1 => 1,\n        _ => n * factorial(n - 1),\n    }\n}\n\n#[cfg(test)]\nmod tests {\n    use super::*;\n\n    #[test]\n    fn test_factorial() {\n        assert_eq!(factorial(0), 1);\n        assert_eq!(factorial(1), 1);\n        assert_eq!(factorial(5), 120);\n    }\n}

Lançons tarpaulin :

cargo tarpaulin --ignore-tests --out Html

Le flag --ignore-tests exclut le code des tests lui-même du rapport. Résultat : 100% de couverture pour cette fonction. Mais compliquons la tâche — ajoutons la gestion des erreurs :

pub fn factorial_safe(n: i32) -> Result<u32, String> {\n    if n < 0 {\n        return Err("Nombre négatif !".to_string());\n    }\n    Ok(factorial(n as u32))\n}

Maintenant, tarpaulin montrera que la branche Err n'est pas couverte par les tests. Ajoutons un test :

#[test]\nfn test_negative() {\n    assert!(factorial_safe(-5).is_err());\n}

Après un nouveau lancement, la couverture sera à nouveau de 100%.

Paramètres avancés de tarpaulin

Pour les grands projets, utilisez :

\n
• --fail-under 80 — sortie en erreur si la couverture est inférieure à 80%.
\n
• --skip-clean — ne pas reconstruire le projet si les modifications sont mineures.
\n
• --engine llvm — utiliser la boîte à outils LLVM (expérimental, mais plus précis).
\n

Outil n°2 : grcov — le roi des intégrations

grcov est un outil plus flexible qui fonctionne avec la boîte à outils LLVM. Il est particulièrement utile si vous utilisez un CI/CD (GitHub Actions, GitLab