Antwoord.

Modultesten in Rust zijn ingebouwd in de taal zelf via ingebouwde macro's, speciale attributen en de cargo-infrastructuur. Historisch gezien zijn testen in C en een aantal andere talen een externe uitbreiding, wat leidt tot afwijkingen in de interface van de productiecodes en tests. In Rust worden tests gecompileerd en uitgevoerd in dezelfde omgeving als de hoofdcode, wat het probleem van "werkt alleen in tests" oplost.

Probleem: Tests kunnen de build vertraagen, niet-informatief of slecht georganiseerd zijn; ook slecht afzonderlijke tests belemmeren het onderhoud van de code en de leesbaarheid.

Oplossing: Tests worden geschreven als speciale functies gemarkeerd met het attribuut #[test] binnen de module mod tests. Alle testcode wordt alleen gecompileerd en uitgevoerd met de sleutel cargo test, het wordt uitgesloten van de productiebuild. Macro's zoals assert_eq!, should_panic en setup-methoden worden gebruikt om de efficiëntie en netheid van het testen te verbeteren.

Voorbeeldcode:

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

Belangrijke kenmerken:

Tests worden alleen gecompileerd bij de build met cargo test, komen niet in de release-binary
Volledige integratie in de taal via attributen en macro's
Eenvoudige organisatie van tests per module, kunnen publieke en privé testfuncties zijn

Vragen met een haakje.

Is het verplicht om tests alleen in de geneste module mod tests te plaatsen?

Niet verplicht, maar het is gebruikelijk voor de isolatie van tests en om te voorkomen dat testcode in de release komt. Het helpt ook bij het gebruik van #[cfg(test)].

Kun je tests alleen op een bepaalde module/bestand uitvoeren?

Ja, je kunt de testnaam of het pad naar deze aangeven met cargo test naam.

Worden privéfuncties getest?

Ja, als de testmodule binnen hetzelfde bestand is gedefinieerd en use super::*; gebruikt, hebben tests toegang tot alle interne functies van dit bestand.

Typische fouten en anti-patronen

Geen scheiding van testmodules van de code (zonder #[cfg(test)])
Duplicatie van code of complexe logica binnen tests
Geen gebruik van assert_eq! of te complexe controles

Voorbeeld uit het leven

Negatieve case

Tests zijn gemengd met de hoofdcode, niet verborgen in #[cfg(test)], gebruiken globale variabelen voor initialisatie.

Voordelen:

Snelle prototyping

Nadelen:

Testcode komt in de release
Tests breken door wijzigingen in de code en zijn niet geïsoleerd

Positieve case

Tests zijn ingekapseld in geneste modules, gebruiken setup-functies en macro's assert_eq! voor verificatie.