Antwort.

Modultests in Rust sind in die Sprache selbst integriert durch eingebaute Makros, spezielle Attribute und die Cargo-Infrastruktur. Historisch gesehen ist das Testen in C und einigen anderen Sprachen eine externe Schicht, was zu einer Diskrepanz zwischen der Schnittstelle des Produktionscodes und den Tests führt. In Rust werden Tests im selben Umfeld kompiliert und ausgeführt wie der Hauptcode, was das Problem "funktioniert nur in Tests" beseitigt.

Problem: Tests können den Build verlangsamen, uninformativ oder schlecht organisiert sein; zudem behindern schlecht isolierte Tests die Wartbarkeit und Lesbarkeit des Codes.

Lösung: Tests werden als spezielle Funktionen mit dem Attribut #[test] innerhalb des Moduls mod tests geschrieben. Der gesamte Testcode wird nur mit dem Schlüssel cargo test kompiliert und ausgeführt, er wird von der Produktionsbuild ausgeschlossen. Makros wie assert_eq!, should_panic und Setup-Methoden werden verwendet, um die Effizienz und Sauberkeit des Testens zu erhöhen.

Beispielcode:

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

Wichtige Merkmale:

Tests werden nur bei einem Build mit cargo test kompiliert, gelangen nicht in das Release-Binary
Vollständige Integration in die Sprache durch Attribute und Makros
Einfache Organisation von Tests in Modulen, es können öffentliche und private Testfunktionen vorhanden sein

Fangfragen.

Muss man Tests unbedingt in ein eingebettetes Modul mod tests einfügen?

Nicht zwingend, aber es ist üblich, um Tests zu isolieren und das Übergreifen von Testcode in Releases zu verhindern. Es hilft auch, #[cfg(test)] zu verwenden.

Kann man Tests nur für ein bestimmtes Modul/Datei ausführen?

Ja, man kann den Namen des Tests oder seinen Pfad mit cargo test name angeben.

Werden private Funktionen getestet?

Ja, wenn das Testmodul innerhalb derselben Datei definiert ist und use super::*; verwendet, haben die Tests Zugriff auf alle internen Funktionen dieser Datei.

Typische Fehler und Anti-Patterns

Fehlende Trennung von Testmodulen und Code (ohne #[cfg(test)])
Code-Duplikation oder komplexe Logik in Tests
Nichtverwendung von assert_eq! oder überkomplizierte Prüfungen

Beispiel aus dem Leben

Negativer Fall

Tests sind mit dem Hauptcode vermischt, nicht versteckt in #[cfg(test)], verwenden globale Variablen zur Initialisierung.

Vorteile:

Schnelles Prototyping

Nachteile:

Testcode gelangt in das Release
Tests brechen aufgrund von Änderungen im Code und sind nicht isoliert

Positiver Fall

Tests sind in eingebetteten Modulen gekapselt, verwenden Setup-Funktionen und Makros assert_eq! zur Überprüfung.