rust-testing

Modèles de test Rust

Modèles de test Rust complets pour écrire des tests fiables et maintenables suivant la méthodologie TDD.

Quand l'utiliser

• Écrire de nouvelles fonctions, méthodes ou traits Rust
• Ajouter une couverture de test à du code existant
• Créer des benchmarks pour du code critique en performance
• Implémenter des tests basés sur les propriétés pour la validation d'entrée
• Suivre le flux de travail TDD dans les projets Rust

Comment ça fonctionne

1. Identifier le code cible — Trouver la fonction, le trait ou le module à tester
2. Écrire un test — Utiliser #[test] dans un module #[cfg(test)], rstest pour les tests paramétrés, ou proptest pour les tests basés sur les propriétés
3. Moquer les dépendances — Utiliser mockall pour isoler l'unité testée
4. Exécuter les tests (ROUGE) — Vérifier que le test échoue avec l'erreur attendue
5. Implémenter (VERT) — Écrire le code minimal pour réussir
6. Refactoriser — Améliorer tout en gardant les tests verts
7. Vérifier la couverture — Utiliser cargo-llvm-cov, viser 80%+

Flux de travail TDD pour Rust

Le cycle ROUGE-VERT-REFACTORISATION

ROUGE       → Écrire d'abord un test qui échoue
VERT        → Écrire le code minimal pour réussir le test
REFACTORISATION → Améliorer le code tout en gardant les tests verts
RÉPÉTER     → Continuer avec l'exigence suivante

TDD pas à pas en Rust

// ROUGE : Écrire le test d'abord, utiliser todo!() comme placeholder
pub fn add(a: i32, b: i32) -> i32 { todo!() }

#[cfg(test)]
mod tests {
    use super::*;
    #[test]
    fn test_add() { assert_eq!(add(2, 3), 5); }
}
// cargo test → panique avec 'not yet implemented'

// VERT : Remplacer todo!() par l'implémentation minimale
pub fn add(a: i32, b: i32) -> i32 { a + b }
// cargo test → SUCCÈS, puis REFACTORISER tout en gardant les tests verts

Tests unitaires

Organisation des tests au niveau du module

// src/user.rs
pub struct User {
    pub name: String,
    pub email: String,
}

impl User {
    pub fn new(name: impl Into<String>, email: impl Into<String>) -> Result<Self, String> {
        let email = email.into();
        if !email.contains('@') {
            return Err(format!("email invalide : {email}"));
        }
        Ok(Self { name: name.into(), email })
    }

    pub fn display_name(&self) -> &str {
        &self.name
    }
}

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

    #[test]
    fn crée_un_utilisateur_avec_un_email_valide() {
        let user = User::new("Alice", "[email protected]").unwrap();
        assert_eq!(user.display_name(), "Alice");
        assert_eq!(user.email, "[email protected]");
    }

    #[test]
    fn rejette_un_email_invalide() {
        let result = User::new("Bob", "pas-un-email");
        assert!(result.is_err());
        assert!(result.unwrap_err().contains("email invalide"));
    }
}

Macros d'assertion

assert_eq!(2 + 2, 4);                                    // Égalité
assert_ne!(2 + 2, 5);                                    // Inégalité
assert!(vec![1, 2, 3].contains(&2));                     // Booléen
assert_eq!(value, 42, "attendu 42 mais obtenu {value}"); // Message personnalisé
assert!((0.1_f64 + 0.2 - 0.3).abs() < f64::EPSILON);   // Comparaison flottante

Test des erreurs et des paniques

Test des retours Result

#[test]
fn parse_retourne_une_erreur_pour_une_entrée_invalide() {
    let result = parse_config("}{invalid");
    assert!(result.is_err());

    // Vérifier une variante d'erreur spécifique
    let err = result.unwrap_err();
    assert!(matches!(err, ConfigError::ParseError(_)));
}

#[test]
fn parse_réussit_pour_une_entrée_valide() -> Result<(), Box<dyn std::error::Error>> {
    let config = parse_config(r#"{"port": 8080}"#)?;
    assert_eq!(config.port, 8080);
    Ok(()) // Le test échoue si n'importe quel ? renvoie Err
}

Test des paniques

#[test]
#[should_panic]
fn panique_sur_une_entrée_vide() {
    process(&[]);
}

#[test]
#[should_panic(expected = "index out of bounds")]
fn panique_avec_un_message_spécifique() {
    let v: Vec<i32> = vec![];
    let _ = v[0];
}

Tests d'intégration

Structure des fichiers

ma_bibliothèque/
├── src/
│   └── lib.rs
├── tests/              # Tests d'intégration
│   ├── api_test.rs     # Chaque fichier est un binaire de test séparé
│   ├── db_test.rs
│   └── common/         # Utilitaires de test partagés
│       └── mod.rs

Écrire des tests d'intégration

// tests/api_test.rs
use ma_bibliothèque::{App, Config};

#[test]
fn cycle_de_vie_complet_dune_requête() {
    let config = Config::test_default();
    let app = App::new(config);

    let response = app.handle_request("/health");
    assert_eq!(response.status, 200);
    assert_eq!(response.body, "OK");
}

Tests asynchrones

Avec Tokio

#[tokio::test]
async fn récupère_les_données_avec_succès() {
    let client = TestClient::new().await;
    let result = client.get("/data").await;
    assert!(result.is_ok());
    assert_eq!(result.unwrap().items.len(), 3);
}

#[tokio::test]
async fn gère_le_timeout() {
    use std::time::Duration;
    let result = tokio::time::timeout(
        Duration::from_millis(100),
        opération_lente(),
    ).await;

    assert!(result.is_err(), "aurait dû expirer");
}

Modèles d'organisation des tests

Tests paramétrés avec rstest

use rstest::{rstest, fixture};

#[rstest]
#[case("hello", 5)]
#[case("", 0)]
#[case("rust", 4)]
fn test_longueur_chaîne(#[case] input: &str, #[case] expected: usize) {
    assert_eq!(input.len(), expected);
}

// Fixtures
#[fixture]
fn test_bd() -> TestBd {
    TestBd::new_in_memory()
}

#[rstest]
fn test_insertion(test_bd: TestBd) {
    test_bd.insert("clé", "valeur");
    assert_eq!(test_bd.get("clé"), Some("valeur".into()));
}

Aides de test

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

    /// Crée un utilisateur de test avec des valeurs par défaut sensibles.
    fn créer_utilisateur(nom: &str) -> Utilisateur {
        Utilisateur::new(nom, &format!("{nom}@test.com")).unwrap()
    }

    #[test]
    fn affichage_utilisateur() {
        let user = créer_utilisateur("alice");
        assert_eq!(user.display_name(), "alice");
    }
}

Tests basés sur les propriétés avec proptest

Tests de propriétés de base

use proptest::prelude::*;

proptest! {
    #[test]
    fn aller_retour_codage_décodage(input in ".*") {
        let encoded = coder(&input);
        let decoded = décoder(&encoded).unwrap();
        assert_eq!(input, decoded);
    }

    #[test]
    fn tri_conserve_la_longueur(mut vec in prop::collection::vec(any::<i32>(), 0..100)) {
        let longueur_originale = vec.len();
        vec.sort();
        assert_eq!(vec.len(), longueur_originale);
    }

    #[test]
    fn tri_produit_un_ensemble_ordonné(mut vec in prop::collection::vec(any::<i32>(), 0..100)) {
        vec.sort();
        for window in vec.windows(2) {
            assert!(window[0] <= window[1]);
        }
    }
}

Stratégies personnalisées

use proptest::prelude::*;

fn email_valide() -> impl Strategy<Value = String> {
    ("[a-z]{1,10}", "[a-z]{1,5}")
        .prop_map(|(user, domaine)| format!("{user}@{domaine}.com"))
}

proptest! {
    #[test]
    fn accepte_les_emails_valides(email in email_valide()) {
        assert!(Utilisateur::new("Test", &email).is_ok());
    }
}

Mocking avec mockall

Mocking basé sur les traits

use mockall::{automock, predicate::eq};

#[automock]
trait UtilisateurRepository {
    fn trouver_par_id(&self, id: u64) -> Option<Utilisateur>;
    fn sauvegarder(&self, user: &Utilisateur) -> Result<(), ErreurStockage>;
}

#[test]
fn service_retourne_utilisateur_quand_trouvé() {
    let mut mock = MockUtilisateurRepository::new();
    mock.expect_trouver_par_id()
        .with(eq(42))
        .times(1)
        .returning(|_| Some(Utilisateur { id: 42, name: "Alice".into() }));

    let service = UtilisateurService::new(Box::new(mock));
    let user = service.obtenir_utilisateur(42).unwrap();
    assert_eq!(user.name, "Alice");
}

#[test]
fn service_retourne_none_quand_non_trouvé() {
    let mut mock = MockUtilisateurRepository::new();
    mock.expect_trouver_par_id()
        .returning(|_| None);

    let service = UtilisateurService::new(Box::new(mock));
    assert!(service.obtenir_utilisateur(99).is_none());
}

Tests de documentation

Documentation exécutable

/// Ajoute deux nombres ensemble.
///
/// # Exemples
///
/// ```
/// use ma_bibliothèque::add;
///
/// assert_eq!(add(2, 3), 5);
/// assert_eq!(add(-1, 1), 0);
/// ```
pub fn add(a: i32, b: i32) -> i32 {
    a + b
}

/// Analyse une chaîne de configuration.
///
/// # Erreurs
///
/// Renvoie `Err` si l'entrée n'est pas un TOML valide.
///
/// ```no_run
/// use ma_bibliothèque::parse_config;
///
/// let config = parse_config(r#"port = 8080"#).unwrap();
/// assert_eq!(config.port, 8080);
/// ```
///
/// ```no_run
/// use ma_bibliothèque::parse_config;
///
/// assert!(parse_config("}{invalid").is_err());
/// ```
pub fn parse_config(input: &str) -> Result<Config, ErreurParse> {
    todo!()
}

Benchmarking avec Criterion

# Cargo.toml
[dev-dependencies]
criterion = { version = "0.5", features = ["html_reports"] }

[[bench]]
name = "benchmark"
harness = false

// benches/benchmark.rs
use criterion::{black_box, criterion_group, criterion_main, Criterion};

fn fibonacci(n: u64) -> u64 {
    match n {
        0 | 1 => n,
        _ => fibonacci(n - 1) + fibonacci(n - 2),
    }
}

fn bench_fibonacci(c: &mut Criterion) {
    c.bench_function("fib 20", |b| b.iter(|| fibonacci(black_box(20))));
}

criterion_group!(benches, bench_fibonacci);
criterion_main!(benches);

Couverture de test

Exécution de la couverture

# Installation : cargo install cargo-llvm-cov (ou utiliser taiki-e/install-action dans CI)
cargo llvm-cov                    # Résumé
cargo llvm-cov --html             # Rapport HTML
cargo llvm-cov --lcov > lcov.info # Format LCOV pour CI
cargo llvm-cov --fail-under-lines 80  # Échouer si en dessous du seuil

Cibles de couverture

Type de code	Cible
Logique métier critique	100%
API publique	90%+
Code général	80%+
Code généré / liaisons FFI	Exclure

Commandes de test

cargo test                        # Exécuter tous les tests
cargo test -- --nocapture         # Afficher la sortie println
cargo test nom_du_test            # Exécuter les tests correspondant au motif
cargo test --lib                  # Tests unitaires uniquement
cargo test --test api_test        # Tests d'intégration uniquement
cargo test --doc                  # Tests de documentation uniquement
cargo test --no-fail-fast         # Ne pas s'arrêter à la première erreur
cargo test -- --ignored           # Exécuter les tests ignorés

Bonnes pratiques

À FAIRE :

• Écrire les tests D'ABORD (TDD)
• Utiliser les modules #[cfg(test)] pour les tests unitaires
• Tester le comportement, pas l'implémentation
• Utiliser des noms de tests descriptifs qui expliquent le scénario
• Préférer assert_eq! à assert! pour de meilleurs messages d'erreur
• Utiliser ? dans les tests qui retournent Result pour une sortie d'erreur plus propre
• Garder les tests indépendants — pas d'état mutable partagé

À NE PAS FAIRE :

• Utiliser #[should_panic] quand vous pouvez tester Result::is_err() à la place
• Moquer tout — préférer les tests d'intégration quand c'est faisable
• Ignorer les tests instables — les corriger ou les mettre en quarantaine
• Utiliser sleep() dans les tests — utiliser des canaux, des barrières ou tokio::time::pause()
• Sauter les tests de chemins d'erreur

Intégration CI

# GitHub Actions
test:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - uses: dtolnay/rust-toolchain@stable
      with:
        components: clippy, rustfmt

    - name: Vérifier le formatage
      run: cargo fmt --check

    - name: Clippy
      run: cargo clippy -- -D warnings

    - name: Exécuter les tests
      run: cargo test

    - uses: taiki-e/install-action@cargo-llvm-cov

    - name: Couverture
      run: cargo llvm-cov --fail-under-lines 80

Souvenez-vous : Les tests sont une documentation. Ils montrent comment votre code est censé être utilisé. Écrivez-les clairement et maintenez-les à jour.