Was ist Modultest? Definition, Beispiele

⚡ Intelligente Zusammenfassung

Beim Modultest werden einzelne Unterprogramme, Unterroutinen, Klassen und Prozeduren geprüft, anstatt des gesamten Programms. Dadurch treten Fehler in einem kleinen, gut verständlichen Codeblock zutage, wo sie kostengünstig zu finden und zu beheben sind.

🎯 Ziel: Ziel ist es, Fehler in einem Modul aufzudecken, nicht zu beweisen, dass das Modul funktioniert.
⚪ Orientierung: Die Technik ist im Wesentlichen eine White-Box-Methode, ergänzt durch Black-Box-Fälle, die aus der Spezifikation abgeleitet werden.
⏩ Parallelität: Es können mehrere Module gleichzeitig getestet werden, was den gesamten Testzeitraum verkürzt.
🔗 Zwei Methoden: Die Module werden entweder schrittweise, inkrementell, oder nicht-inkrementell in einem Durchgang kombiniert.
🧰 Gerüst: Treiber liefern Testdaten an ein Modul, während Stubs als Ersatz für die von ihnen aufgerufenen Module dienen.
🆚 Eigentümer: Tester schreiben Modultests nach der Codierung, während Entwickler Unit-Tests während der Codierung schreiben.
⚠️ Challenges: Nicht-inkrementelles Arbeiten, missverstandene Test-Doubles und häufiges Debuggen beanspruchen den größten Teil des Aufwands.

Was ist Modultest?

Modulprüfung Modultests sind eine Art von Softwaretests, die einzelne Unterprogramme, Unterroutinen, Klassen oder Prozeduren eines Programms überprüfen. Anstatt das gesamte Softwareprogramm auf einmal zu testen, empfiehlt der Modultest, die kleineren Bausteine des Programms zu prüfen.

Modultests sind größtenteils White-Box-orientiert. Ziel von Modultests ist nicht der Nachweis der korrekten Funktion des Moduls, sondern das Aufdecken eines Fehlers. Diese Umkehrung ist wichtig: Ein Testlauf, der nichts findet, hat wenig bestätigt, wohingegen ein Testlauf, der einen Fehler aufdeckt, seinen Zweck erfüllt hat.

Durch das Testen auf Modulebene wird auch die Parallelisierung des Testprozesses ermöglicht, da so die Möglichkeit geschaffen wird, mehrere Module gleichzeitig zu testen, anstatt auf einen vollständigen Build zu warten.

Warum Modultests durchführen?

Modultests werden empfohlen, da sie die Wirtschaftlichkeit der Fehlererkennung verändern.

Die Wahrscheinlichkeit, Fehler oder Bugs in kleineren Programmteilen zu identifizieren, steigt.
Mehrere Module können gleichzeitig getestet werden, daher unterstützt der Ansatz parallele Tests.
Die Komplexität der Tests lässt sich leicht bewältigen, da jedes Modul für sich betrachtet wird.
Ein Defekt, der in einem Modul gefunden wurde, ist tracEs ist auf eine kleine Menge Code beschränkt, wodurch sich die Debugging-Zeit drastisch reduziert.

Wie führt man Modultests durch?

Designing a Testfall ist ein wichtiger Bestandteil des Modultests. Beim Entwurf von Testfällen für einen Modultest muss der Tester zwei Dinge berücksichtigen.

Spezifikation für das Modul
Der Quellcode des Moduls

Analysieren Sie die Logik des Moduls mithilfe einer oder mehrerer der folgenden Methoden: weiße Kiste Methoden anwenden und diese Testfälle anschließend durch die Anwendung ergänzen. Flugschreiber Methoden zur Modulspezifikation. Realistische Werte sind ebenso wichtig wie die gewählten Pfade, also bereiten Sie die Testdaten parallel zu den Fällen und nicht im Nachhinein.

Sobald die Testfälle entworfen sind, besteht der nächste Schritt darin, die Module für die Tests zu kombinieren. Die verwendete Methode ist entweder eine inkremental oder die nicht-inkrementell Methode.

Nichtinkrementelles Verfahren — Alle Module werden einzeln getestet. Zuerst werden alle Module kombiniert und dann das gesamte Programm getestet.
Inkrementelle Methode — Jedes Modul wird zunächst getestet und dann schrittweise der Testsammlung hinzugefügt. Es wird ein schrittweiser Wiederholungstest durchgeführt.
Beim inkrementellen Testen gibt es zwei Ansätze. von oben nach unten und von unten nach oben Testen.
Um das Modul mit den ausgewählten Daten auszuführen, wird ein Treiber benötigt, der die Testdaten bereitstellt, die Ausführung überwacht und die Ergebnisse erfasst.

Die Wahl zwischen den beiden Methoden ist ein Kompromiss zwischen Einrichtungsaufwand und Diagnostizierbarkeit.

Aspekt	Inkrementelle Methode	Nichtinkrementelles Verfahren
Kombination	Ein Modul nach dem anderen, hinzugefügt zu einer getesteten Sammlung	Alle Module kombiniert und anschließend gemeinsam getestet
Gerüst erforderlich	Mehr Fahrer und Stubs, schrittweise geschrieben	Weniger Test-Doubles, da reale Module vorhanden sind
Fehleranalyse	Stark – ein Fehlerpunkt liegt an dem gerade hinzugefügten Modul.	Schwach – ein Fehler kann überall auftreten
am besten geeignet für	Große Systeme mit vielen interagierenden Modulen	Kleine Programme mit wenigen Modulen und geringer Kopplung

Treiber und Stubs im Modultest

Der oben erwähnte Treiber ist die eine Hälfte eines Paares. Da sich ein zu testendes Modul selten am Anfang oder Ende der Aufrufkette befindet, ersetzen Tester fehlenden Code auf beiden Seiten durch Dummy-Code.

LED Treiber — ersetzt das aufrufende Modul über dem zu testenden Modul. Es liefert die Testdaten, ruft das Modul auf, überwacht die Ausführung und erfasst die Ergebnisse. Bottom-up-Tests sind von Treibern abhängig, da die unteren Module vor den höheren bereit sind.
Stummel — ersetzt ein aufgerufenes Modul unterhalb des zu testenden Moduls. Es nimmt den Aufruf entgegen und gibt eine festgelegte, bekannte Antwort zurück, damit das zu testende Modul seinen Ablauf abschließen kann. Top-Down-Tests sind auf Stubs angewiesen, da die übergeordneten Module zuerst bereit sind.

Ein ausgearbeitetes Beispiel verdeutlicht die Zuordnung. Wenn ein Modul zur Zahlungsberechnung fertig ist, die zugehörige Checkout-Seite aber noch nicht, übergibt ein Treiber dem Modul die Bestellsummen und protokolliert die Rückgabewerte. Ist der vom Modul aufgerufene Steuerabfragedienst ebenfalls noch nicht fertig, gibt ein Stub einen festen Steuersatz zurück, damit die Berechnung trotzdem ausgeführt werden kann. Beide Gerüstbausteine werden nicht mitgeliefert; sie werden verworfen, sobald die eigentlichen Module verfügbar sind. Daher wird das Missverständnis von Test-Doubles später als wiederkehrende Herausforderung aufgeführt.

Beispieltipps für Modultests

Hier sind ein paar Tipps, die Sie vor dem Testen von Modulen beachten sollten.

RevSehen Sie sich die Testfälle an, bevor Sie sie verwenden.
Vermeiden Sie Verwirrung über die Ursache von Abweichungen.
Nutzen Sie automatisierte Testwerkzeuge.
Untersuchen Sie die Variablen, die unverändert bleiben sollten.
Um Selbsttests zu vermeiden, sollten die Module zwischen den Testern getauscht werden.
Die Testfälle wiederverwenden.

Der fünfte Tipp ist wichtiger, als seine Kürze vermuten lässt. Ein Entwickler, der nur das gerade geschriebene Modul testet, wiederholt dieselben Annahmen, die den Fehler verursacht haben. Daher ist der Austausch von Modulen zwischen verschiedenen Personen eine der kostengünstigsten Möglichkeiten zur Qualitätsverbesserung.

Unit-Tests vs. Modultests

Die beiden Begriffe werden in vielen Teams synonym verwendet, doch Urheberschaft und Geltungsbereich unterscheiden sich.

Modultests	Unit Tests
Modultests sind eine Sammlung von Tests, die von einem Tester geschrieben werden, nachdem ein Entwickler Code geschrieben hat	Unit-Tests sind eine Sammlung von Tests, die von einem Entwickler während des Softwareentwicklungsprozesses geschrieben wurden.
Modultests können die Kombination der Unit-Tests umfassen.	Komponententests können Komponenten isoliert testen

Modultests vs. Komponententests vs. Integrationstests

Die Modulprüfung liegt zudem neben zwei benachbarten Ebenen, die leicht mit ihr verwechselt werden können. Die Tabelle unterscheidet sie danach, was geprüft wird und wer die Prüfung üblicherweise durchführt.

Aspekt	Modulprüfung	Bauteilprüfung	Integrationstests
Im Test	Ein Unterprogramm, eine Klasse oder ein Verfahren	Eine in sich geschlossene Komponente mit ihren unmittelbaren Abhängigkeiten	Die Schnittstellen zwischen kombinierten Modulen
Üblicher Eigentümer	Tester, nachdem der Code geschrieben wurde	Tester	Integrationstester
Gerüst	Treiber und Stubs	Platzhalter für externe Abhängigkeiten	Immer weniger Testdoubles
Defekt aufgedeckt	Logikfehler im Modul	Verhaltensfehler in der Komponente	Schnittstellen- und Datenübergabefehler

Im alltäglichen Gebrauch Komponententests und Modultests werden häufig als ein und dieselbe Aktivität behandelt, Integrationstests beginnt erst, wenn jedes einzelne Modul nacheinander erfolgreich abgeschlossen wurde.

Herausforderungen beim Modultesten

Dies sind die Herausforderungen, denen Teams am häufigsten begegnen, wenn Modultests eingeführt werden.

Nicht-inkrementelle Tests erfordern mehr Arbeit — Wenn man zuerst alles kombiniert, bedeutet das, dass ein einziger Fehler dazu führen kann, dass die Tester das gesamte Programm erneut durchlaufen müssen.
Missverständnisse beim Test verdoppeln — Ein Stub, der einen unrealistischen Wert zurückgibt, erzeugt einen grünen Lauf, der nichts beweist.
Debugging-Tests oft — Gerüstcode birgt seine eigenen Mängel, und Zeit, die mit der Behebung eines Treiberfehlers verbracht wird, ist Zeit, die nicht mit dem Testen des Moduls verbracht werden kann.
Muss den Code verstehen — Die Ausrichtung nach dem White-Box-Prinzip bedeutet, dass ein Tester, der das Modul nicht lesen kann, auch keine sinnvollen Testfälle dafür entwerfen kann.

Häufig gestellte Fragen

Die xUnit-Familie deckt die meisten Sprachen ab. Mocking-Bibliotheken liefern die Stubs, und ein Coverage-Tool zeigt an, welche Pfade erreicht wurden. Die Wahl der Sprache richtet sich nach der Sprache des Moduls, nicht nach dem Testniveau.

Ein Modell liest den Modulquellcode, zählt die Zweige auf und schlägt für jeden Zweig einen Fall vor, einschließlich Grenzwerten, die bei einem manuellen Durchlauf oft übersehen werden. RevEin Blick bleibt notwendig, da generierte Fälle aussagen, was der Code tut, anstatt das, was die Spezifikation vorschreibt.

Ja, und beim Scaffolding leisten solche Assistenten ihre besten Dienste, da ein Treiber oder Stub repetitiver Code mit bekannter Struktur ist. Die zurückgegebenen Werte erfordern jedoch weiterhin eine menschliche Entscheidung, denn ein plausibel aussehender Stub kann genau den Fehler verschleiern, nach dem gesucht wird.

Es genügt, dass jeder Zweig und jede Grenze im Modul mindestens einmal durchlaufen wurde. Ein prozentuales Ziel allein ist irreführend, da selbst bei hoher Anweisungsabdeckung ganze Entscheidungskonstellationen ungetestet bleiben können.

Dies ist die erste Teststufe, die nach der Kompilierung eines Moduls und vor der gemeinsamen Ausführung seiner Schnittstellen auf den ausgelieferten Code angewendet wird. Aus diesem Grund erreichen hier erkannte Fehler niemals die Integrations- oder Systemphase.

Folgen Sie dem vorhandenen Code. Top-Down eignet sich für Projekte, bei denen die Steuerlogik zuerst geschrieben und die unteren Module anschließend mit Platzhaltern versehen werden; Bottom-Up eignet sich für Projekte, bei denen die Hilfsmodule zuerst implementiert und von den Treibern aufgerufen werden.

Das Modul lässt sich problemlos kompilieren, seine Spezifikation ist verfügbar, seine Abhängigkeiten sind entweder vorhanden oder als Platzhalter implementiert, und die Testdaten sind bereit. Beginnt man ohne Spezifikation, reduziert sich die Übung auf eine Beschreibung des Codes.

Tests können niemals beweisen, dass ein Modul fehlerfrei ist, sondern nur, dass es die getesteten Fälle überstanden hat. Daher liefern Tests, die darauf abzielen, das Modul zum Absturz zu bringen, mehr Informationen als Tests, die voraussichtlich erfolgreich verlaufen.