Risposta.

Il testing unitario in Rust è integrato nel linguaggio stesso attraverso macro incorporate, attributi speciali e un'infrastruttura cargo. Storicamente, in C e in alcuni altri linguaggi, il testing è un'aggiunta esterna, il che porta a discrepanze tra l'interfaccia del codice di produzione e i test. In Rust, i test sono compilati ed eseguiti nello stesso ambiente del codice principale, eliminando il problema "funziona solo nei test".

Problema: i test possono rallentare la compilazione, essere poco informativi o mal organizzati; test non ben isolati ostacolano la manutenzione del codice e la sua leggibilità.

Soluzione: i test sono scritti come funzioni speciali contrassegnate dall'attributo #[test] all'interno del modulo mod tests. Tutto il codice di test viene compilato ed eseguito solo con il comando cargo test, viene escluso dalla build di produzione. Macro come assert_eq!, should_panic e metodi di setup vengono utilizzati per aumentare l'efficacia e la pulizia del testing.

Esempio di codice:

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);
    }
}

Caratteristiche chiave:

I test vengono compilati solo durante la build con cargo test, non vengono inclusi nel binario di rilascio
Integrazione completa nel linguaggio tramite attributi e macro
Facile organizzazione dei test in moduli, possono esserci funzioni di test pubbliche e private

Domande trabocchetto.

È obbligatorio inserire i test solo nel modulo annidato mod tests?

Non è obbligatorio, ma è prassi comune per isolare i test e prevenire l'esposizione del codice di test nella release. Aiuta anche nell'uso di #[cfg(test)].

È possibile eseguire test solo su un determinato modulo/file?

Sì, è possibile specificare il nome del test o il percorso a esso usando cargo test nome.

Le funzioni private vengono testate?

Sì, se il modulo di test è definito all'interno dello stesso file e utilizza use super::*;, i test hanno accesso a tutte le funzioni interne di quel file.

Errori comuni e anti-pattern

Mancanza di separazione dei moduli di test dal codice (senza #[cfg(test)])
Duplicazione del codice o logica complicata all'interno dei test
Non utilizzo di assert_eq! o controlli complicati

Esempio dalla vita reale

Caso negativo

I test sono mescolati con il codice principale, non sono nascosti in #[cfg(test)], utilizzano variabili globali per l'inizializzazione.

Vantaggi:

Prototipazione rapida

Svantaggi:

Il codice di test entra nella release
I test si rompono a causa delle modifiche nel codice e non sono isolati

Caso positivo

I test sono incapsulati in moduli annidati, utilizzano funzioni di setup e macro assert_eq! per le verifiche.