Réponse.

Les tests unitaires en Rust sont intégrés dans le langage lui-même grâce à des macros intégrées, des attributs spéciaux et l'infrastructure cargo. Historiquement, dans C et d'autres langages, les tests sont une superposition externe, ce qui entraîne un décalage entre l'interface du code de production et celle des tests. En Rust, les tests sont compilés et exécutés dans le même environnement que le code principal, ce qui élimine le problème du "fonctionne seulement dans les tests".

Problème : les tests peuvent ralentir la compilation, être peu informatifs, ou mal organisés ; de plus, des tests mal isolés compliquent la maintenance du code et sa lisibilité.

Solution : les tests sont écrits comme des fonctions spéciales marquées par l'attribut #[test] à l'intérieur d'un module mod tests. Tout le code de test est compilé et exécuté uniquement avec la clé cargo test, il est exclu de la compilation de production. Des macros comme assert_eq!, should_panic et des méthodes de setup sont utilisées pour améliorer l'efficacité et la clarté des tests.

Exemple de code :

pub fn add(a: i32, b: i32) -> i32 {
    a + b
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_add() {
        assert_eq!(add(2, 2), 4);
    }
}

Caractéristiques clés :

Les tests ne compilent que lors de la compilation avec cargo test et ne figurent pas dans le binaire de production
Intégration complète dans le langage grâce aux attributs et macros
Organisation facile des tests par modules, avec des fonctions de test publiques et privées possibles

Questions pièges.

Est-il obligatoire de placer les tests uniquement dans le module imbriqué mod tests ?

Non, ce n'est pas obligatoire, mais c'est courant pour isoler les tests et éviter les fuites de code de test dans les versions. Cela aide également à utiliser #[cfg(test)].

Peut-on exécuter des tests uniquement sur un module/fichier spécifique ?

Oui, il est possible d'indiquer le nom du test ou son chemin à l'aide de cargo test nom.

Les fonctions privées sont-elles testées ?

Oui, si le module de test est défini dans le même fichier et utilise use super::*;, les tests peuvent accéder à toutes les fonctions internes de ce fichier.

Erreurs courantes et anti-patterns

Absence de séparation des modules de test du code (sans #[cfg(test)])
Duplication de code ou logique complexe à l'intérieur des tests
Non-utilisation d'assert_eq! ou vérifications trop compliquées

Exemple de la vie réelle

Cas négatif

Les tests sont mélangés avec le code principal, non cachés dans #[cfg(test)], utilisant des variables globales pour l'initialisation.

Avantages :

Prototype rapide

Inconvénients :

Le code de test pénètre dans la version
Les tests échouent à cause de modifications du code et ne sont pas isolés

Cas positif

Les tests sont encapsulés dans des modules imbriqués, utilisant des fonctions de setup et des macros assert_eq! pour les vérifications.