Antwort.

Hintergrund des Themas

Das Testen von Programmcode ist einer der ältesten und wichtigsten Prozesse in der Softwareentwicklungsbranche. In vielen Programmiersprachen werden jedoch Testbibliotheken separat bereitgestellt, und die Integration von Tests in den Hauptcode kann undurchsichtig oder unpraktisch sein. In Rust wurde die Sprache seit den ersten Versionen mit Unterstützung für explizite Modultests "out of the box" konzipiert.

Problem

In vielen traditionellen Sprachen sind Tests separat angeordnet oder erfordern das Einrichten spezifischer Frameworks und Builder. Dies erschwert die Zusammenarbeit, erhöht das Risiko von Entkoppelungen zwischen der Hauptlogik und den Tests und macht die Durchführung von Integrations- und Modultests komplizierter.

Lösung

Rust integriert das Testsystem direkt auf Sprachebene: Das Modul #[cfg(test)], die Direktive #[test] und das Tool cargo test ermöglichen das Erstellen, Ausführen und Verwalten von Tests innerhalb des Quellcodes. Dies gewährleistet eine enge Verbindung zwischen Code und den ihn überprüfenden Tests, garantiert die Einfachheit des Teststarts und die Automatisierung von CI/CD-Prozessen.

Beispielcode:

// Tests werden automatisch durch `cargo test` kompiliert und ausgeführt
#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn it_adds_two() {
        assert_eq!(2 + 2, 4);
    }
}

Schlüsselmerkmale:

• Integration des Testens — Tests werden im selben Quellbaum wie die Hauptlogik geschrieben, was die Wartung erleichtert.
• Einfachheit des Starts und der Verwaltung — ein Befehl (cargo test) startet alle gefundenen Tests.
• Isolierung der getesteten Module — die Verwendung von Namensräumen und des speziellen Attributs #[cfg(test)] ermöglicht es, Tests nicht in den Release-Build einzubeziehen.

Fangfragen.

Kann man instabile oder private Funktionen in Tests verwenden und wie geht das?

Ja, das ist möglich. Innerhalb des Testmoduls, das mit #[cfg(test)] deklariert ist, sehen Tests sowohl die öffentliche als auch die private API des aktuellen Moduls. Das bedeutet, dass Sie Implementierungsdetails direkt testen können. Aus einem anderen Modul jedoch nur über die öffentliche Schnittstelle.

Beispiel:

fn private_internal(x: i32) -> i32 { x + 1 }

#[cfg(test)]
mod tests {
    use super::*;
    #[test]
    fn test_private() {
        assert_eq!(private_internal(41), 42);
    }
}

Werden Tests mit gleichen Namen zwischen verschiedenen Modulen Konflikte verursachen?

Nein, die Testnamen sind nur innerhalb ihres Moduls sichtbar. Tests in verschiedenen Modulen können gleich benannt sein, da der Compiler sie anhand des vollständigen Pfades (Namensraum) unterscheidet.

Beispiel:

mod a {
    #[cfg(test)]
    mod tests {
        #[test]
        fn basic() {}
    }
}
mod b {
    #[cfg(test)]
    mod tests {
        #[test]
        fn basic() {}
    }
}

Kann man einen bestimmten Test oder einen Teil der Testsuite ausführen?

Ja, das ist möglich, indem man den Testnamen filtert: cargo test test_name. Dies ist praktisch für das Debuggen großer Suites.

Beispiel:

cargo test only_this_test

Typische Fehler und Anti-Patterns

• Lange, nicht-atomare Tests schreiben, die mehrere Aspekte einer Funktion gleichzeitig überprüfen.
• Tests sofort kommentieren oder löschen, die bei Änderungen am Code "brechen", anstatt die Ursache zu suchen und zu beheben.
• Abhängigkeit von Tests vom globalen Zustand: unbereinigte oder nicht-reversible Aktionen durchführen (z.B. Dateien erstellen, die nicht gelöscht werden).

Beispiel aus der Praxis

Negativer Fall

Ein Entwickler hat die Tests in ein separates Projekt ohne Zugriff auf private Funktionen und mit einer anderen Verzeichnisstruktur verschoben. Aufgrund von Änderungen in der Hauptbibliothek blieben die Tests schnell hinterher und wurden irrelevant.

Vorteile: Tests können isoliert durchgeführt werden, um ein unabsichtliches Erreichen von Testmodulen im Release-Build zu vermeiden.

Nachteile: Verlust der Synchronisation, Unfähigkeit, interne Details zu testen, hohe Wartungskosten und Risiko der Irrelevanz der Tests.

Positiver Fall

Tests werden direkt in denselben Modulen geschrieben wie die Hauptlogik, kleine atomare Testfälle testen die private und öffentliche API. Ein Neuling kann sich schnell in die Funktionsweise des Moduls durch die Tests einarbeiten.

Vorteile: Maximale Unterstützung der Synchronisation, Transparenz, beschleunigtes lokales Testen, Eignung für testgetriebene Entwicklung.

Nachteile: Zunahme der Codezeilen in den Quelldateien, potenzieller Anstieg der Komplexität bei einer großen Anzahl von Tests.