Réponse.

Historique de la question

Les tests du code source sont l'un des processus les plus anciens et les plus importants dans l'industrie du développement. Cependant, dans de nombreux langages, les bibliothèques de tests sont fournies séparément, et l'intégration des tests dans le code principal peut être opaque ou peu pratique. En Rust, dès ses premières versions, le langage a été conçu avec un support explicite pour les tests modulaires "prêts à l'emploi".

Problème

Dans de nombreux langages traditionnels, les tests sont situés séparément ou nécessitent des configurations spécifiques de frameworks et d'outils de compilation. Cela complique le développement collaboratif, augmente le risque de désynchronisation entre la logique principale et les tests, et rend difficile l'exécution de tests d'intégration et de tests modulaires.

Solution

Rust intègre un système de tests directement au niveau du langage : le module #[cfg(test)], la directive #[test] et l'outil cargo test permettent de créer, d'exécuter et de contrôler les tests au sein du code source. Cela garantit un lien étroit entre le code et les tests qui le vérifient, assure une facilité d'exécution des tests et d'automatisation des processus CI/CD.

Exemple de code :

// tests automatiquement compilés et exécutés par `cargo test`
#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn it_adds_two() {
        assert_eq!(2 + 2, 4);
    }
}

Caractéristiques clés :

• Intégration des tests — les tests sont écrits dans le même arbre de sources que la logique principale, ce qui facilite leur maintenance.
• Simplicité d'exécution et de gestion — une seule commande (cargo test) exécute tous les tests détectés.
• Isolation des modules testés — l'utilisation de l'espace de noms et de l'attribut spécial #[cfg(test)] permet de ne pas inclure les tests dans la compilation de production.

Questions pièges.

Peut-on utiliser des fonctions instables ou privées dans les tests, et comment le faire ?

Oui, c'est possible. À l'intérieur du module de tests, déclaré comme #[cfg(test)], les tests voient non seulement l'API publique, mais aussi l'API privée du module courant. Cela signifie que vous pouvez tester les détails de l'implémentation directement. Cependant, depuis un autre module — seulement via l'interface publique.

Exemple :

fn private_internal(x: i32) -> i32 { x + 1 }

#[cfg(test)]
mod tests {
    use super::*;
    #[test]
    fn test_private() {
        assert_eq!(private_internal(41), 42);
    }
}

Les tests avec des noms identiques vont-ils entrer en conflit entre différents modules ?

Non, les noms des tests sont visibles uniquement à l'intérieur de leur module. Les tests de différents modules peuvent avoir le même nom, car le compilateur les distingue par le chemin complet (namespace).

Exemple :

mod a {
    #[cfg(test)]
    mod tests {
        #[test]
        fn basic() {}
    }
}
mod b {
    #[cfg(test)]
    mod tests {
        #[test]
        fn basic() {}
    }
}

Peut-on exécuter un test particulier ou une partie d'un ensemble de tests ?

Oui, par le filtrage du nom du test : cargo test nom_du_test. Cela est pratique pour le débogage de grands ensembles.

Exemple :

cargo test only_this_test

Erreurs typiques et anti-patterns

• Écrire de longs tests non atomiques vérifiant plusieurs aspects de la fonction à la fois.
• Commenter ou supprimer immédiatement les tests qui ont commencé à "casser" lors des modifications du code, au lieu de chercher et de corriger la cause.
• Dépendance du test à l'état global : effectuer des actions non nettoyées ou non réversibles (par exemple, créer des fichiers qui ne sont pas supprimés).

Exemple de la vie réelle

Cas négatif

Un développeur a déplacé les tests dans un projet séparé sans accès aux fonctions privées et avec une autre structure de répertoires. En raison des changements dans la bibliothèque principale, les tests ont rapidement commencé à prendre du retard et à perdre de leur pertinence.

Avantages : On peut isoler les tests, éviter que les modules de test ne se retrouvent accidentellement dans la compilation de production.

Inconvénients : Perte de synchronisation, impossibilité de tester les détails internes, grande complexité de maintenance et risque d'obsolescence des tests.

Cas positif

Les tests sont écrits directement dans les mêmes modules que la logique principale, de petits cas de tests atomiques vérifient l'API publique et privée. Un débutant comprend rapidement le fonctionnement du module à travers les tests.

Avantages : Support maximal de la synchronisation, transparence, tests locaux rapides, convenance pour le développement guidé par les tests.

Inconvénients : Augmentation du nombre de lignes de code dans les fichiers source, risque potentiel d'augmentation de la complexité avec un grand nombre de tests.