Unit-Testing prüft die kleinsten funktionierenden Teile eines Programms einzeln, bevor sie zu Funktionen zusammengesetzt werden. Entwickler schreiben jeden Unit-Test als kurzes Stück Code, das in Sekunden automatisch läuft. Da jeder Test einen Teil isoliert betrachtet, zeigt ein Fehlschlag direkt auf den fehlerhaften Code.
Von allen Prüfungen, die ein Produkt vor dem Release durchläuft, ist Unit-Testing diejenige, die ein QA-Team in der Regel nicht selbst durchführt, denn diese Arbeit gehört zu den Entwicklern. Sobald sich jede Einheit korrekt verhält, kann sich die QA-Automatisierung auf das konzentrieren, was Unit-Tests nicht sehen: wie die Teile in echten Funktionen zusammenspielen.
Was ist Unit-Testing und was prüft es?
Das International Software Testing Qualifications Board (ISTQB) definiert Unit-Testing als Teststufe mit dem Schwerpunkt auf der Bewertung „des kleinsten isoliert testbaren Codeteils“. In den meisten Programmen ist dieser Teil eine Funktion, also ein kurzer Codeblock, der eine Eingabe entgegennimmt und ein Ergebnis zurückgibt.
Isolation bedeutet, die Einheit von der Datenbank, dem Zahlungsanbieter und dem Login-Dienst zu trennen. Entwickler kappen diese Verbindungen mit Platzhaltern, sogenannten Mocks und Stubs: einfache Attrappen externer Dienste, die immer dieselbe Antwort liefern. Dadurch schlägt der Test nur fehl, wenn die Einheit selbst ein Problem hat.
Ein Beispiel: Ein Onlineshop gewährt 10 % Rabatt auf jeden Einkauf über 100 €. Ein Test für die Rabattfunktion könnte eine Bestellung über 150 € eingeben und prüfen, ob als Summe 135 € herauskommt. Ein zweiter Test könnte genau 100 € ausprobieren, um die Grenze der Regel zu prüfen. Ein dritter könnte einen negativen Betrag senden, um sicherzustellen, dass der Code diese Eingabe ablehnt. Alle drei Tests sind fast sofort fertig, ohne Warenkorb, Kunden oder Zahlungsseite.
Isolation hat allerdings eine Grenze: Unit-Testing kann Ihnen nicht sagen, ob die Teile zusammen funktionieren. So kann die Rabattfunktion jeden Test bestehen, während die Checkout-Seite trotzdem den vollen Preis anzeigt.
Wer schreibt Unit-Tests?
Entwickler schreiben und pflegen Unit-Tests im selben Projekt wie den Produktcode. Dafür nutzt jeder Programmierer ein Test-Framework, also ein fertiges Werkzeugset zum Schreiben und Starten von Prüfungen. Bekannte Beispiele sind JUnit für Java, pytest für Python und Jest für JavaScript. Jeder Unit-Test läuft zuerst auf dem Rechner des Entwicklers. Anschließend wiederholt sich derselbe Test in der CI-Pipeline (Continuous Integration), einem automatisierten System, das das Produkt nach jeder Codeänderung neu baut und prüft.
Schnelles Feedback ist ein Grund, warum diese Aufgabe bei den Entwicklern liegt. Eine gut aufgebaute Testsuite, also die vollständige Sammlung der Unit-Tests eines Produkts, ist innerhalb weniger Minuten durchgelaufen. Diese Geschwindigkeit erlaubt es, einen Fehler zu beheben, solange der Code noch frisch im Kopf ist. Der andere Grund: Wer diese Tests schreibt, muss den Produktcode lesen und ändern, und das ist Alltagsarbeit für Entwickler.
QA-Ingenieure haben beim Unit-Testing trotzdem eine Rolle. Bei QAwerk prüfen wir Unit-Tests gemeinsam mit den Entwicklern, die sie schreiben, und listen die Situationen auf, die noch kein Test abdeckt, zum Beispiel ein leeres Formularfeld, eine ungewöhnlich große Bestellung oder eine abgebrochene Internetverbindung. Sobald es neue Tests für diese Lücken gibt, zeigt ein erfolgreicher Durchlauf, dass der Code auch damit umgehen kann.
Wo steht Unit-Testing in der Testpyramide?
Viele Softwareteams ordnen ihre Prüfungen nach der Testpyramide, einem Diagramm, das Tests nach Umfang und Geschwindigkeit sortiert. Unit-Tests bilden die breite Basis, weil sie am günstigsten zu schreiben und am schnellsten auszuführen sind. Ein Produkt kann deshalb leicht Tausende davon haben. Integrationstests liegen in der Mitte und prüfen, wie einzelne Teile zusammenarbeiten. An der schmalen Spitze folgen End-to-End-Tests einer kompletten User Journey, etwa der Registrierung und Bezahlung eines Abonnements.
Die Form der Pyramide spiegelt die Kosten wider. Ein Unit-Test läuft in Sekunden, ein skriptgesteuerter Kauf in einem echten Browser kann dagegen Minuten dauern. Der längere Durchlauf kann außerdem aus Gründen fehlschlagen, die nichts mit dem Code zu tun haben, etwa wegen eines schwachen WLAN-Signals. Deshalb reservieren Teams langsame Browserdurchläufe für vollständige User Journeys und testen einzelne Regeln und Verbindungen auf den unteren Ebenen.
Die meisten Softwareprojekte durchlaufen vier Standard-Teststufen in dieser Reihenfolge: Unit-, Integrations-, System- und Abnahmetest. End-to-End-Tests laufen meist in den letzten beiden, sobald das gesamte Produkt zusammengesetzt ist. Unser Leitfaden zu den Phasen des Softwaretestens geht alle vier durch.
Unit-Testing vs. Integrationstests vs. End-to-End-Tests
Unit-, Integrations- und End-to-End-Tests bilden die drei Ebenen der Pyramide. Deshalb tauchen diese Begriffe in Projektplänen und Statusberichten am häufigsten auf. Jeder Testtyp findet eine andere Art von Problem. Dieser Unterschied ist wichtig, wenn Sie einen Bericht lesen: „Alle Unit-Tests bestanden“ bestätigt, dass jedes abgedeckte Codestück für sich funktioniert, zeigt aber noch nicht, dass ein Kunde einen Kauf abschließen kann. Der folgende Vergleich zeigt auch, warum Teams End-to-End-Prüfungen auf ein Minimum beschränken und sich für die meisten Details auf die unteren Ebenen verlassen.
Was geprüft wird
Eine Funktion oder ein kleines Codestück
Eine Verbindung zwischen Teilen oder Diensten
Eine vollständige User Journey
Typisches Beispiel
Die Passwortregel lehnt alles unter 8 Zeichen ab
Eine erfolgreiche Zahlung aktualisiert den Bestellstatus
Ein Kunde durchsucht den Katalog, bezahlt eine Jacke und erhält eine Bestätigungs-E-Mail
Wer die Tests meist schreibt
Entwickler
Entwickler und QA-Ingenieure
QA-Automatisierungsingenieure
Wie lange ein Test dauert
Höchstens ein paar Sekunden
Bis zu einer Minute
Mehrere Minuten
Was ein Fehlschlag verrät
Genau welche Funktion defekt ist
Welche Verbindung defekt ist
Dass eine User Journey defekt ist, aber selten wo
Best Practices für Unit-Testing: Woran man gute Tests erkennt
Die folgenden Best Practices für Unit-Testing sind zugleich Fragen, die Sie Ihren Entwicklern stellen können:
- Ist die gesamte Testsuite in Minuten durchgelaufen? Entwickler überspringen langsame Durchläufe gern, und übersprungene Prüfungen finden nichts.
- Ist jeder Test auf ein Verhalten beschränkt? So benennt ein Fehlschlag das Problem in klaren Worten, etwa „lehnt eine leere E-Mail-Adresse ab“.
- Kommen die Tests ohne echte externe Dienste aus? Prüfungen, die eine echte Datenbank oder einen echten Zahlungsanbieter aufrufen, schlagen fehl, sobald diese Systeme langsam sind. Nach genügend Fehlalarmen ignorieren die Leute Fehlschläge irgendwann ganz.
- Werden Fehlerfälle getestet? Schwere Bugs verstecken sich oft im Code, der fehlerhafte Eingaben verarbeitet. Eine Funktion, die ein Geburtsdatum einliest, braucht neben dem Normalfall auch Tests für ein leeres Feld und ein falsches Format.
- Gilt die Abdeckung als Orientierung oder als Zielvorgabe? Die Codeabdeckung ist der Anteil eines Programms, den die Tests tatsächlich ausführen. Ein niedriger Prozentsatz weist auf ungetestete Bereiche hin. Ein hoher Prozentsatz beweist für sich allein jedoch wenig, denn ein Test kann eine Codezeile ausführen, ohne das Ergebnis zu prüfen.
- Läuft die Suite bei jeder Änderung? Die CI-Pipeline sollte die Tests automatisch starten und jedes Update, das einen Fehlschlag verursacht, davon abhalten, in die Hauptversion des Produkts zu gelangen.
- Wer prüft KI-generierte Tests? KI-Tools schreiben Unit-Tests inzwischen in Sekunden und sparen damit echte Zeit. Als Meta einen internen Testgenerator untersuchte, übernahmen die Ingenieure jedoch 73 % der vorgeschlagenen Tests und lehnten den Rest nach der Prüfung ab. Deshalb sollte ein Programmierer oder QA-Spezialist jeden generierten Test freigeben, bevor er in die Suite aufgenommen wird.
Welche Rolle spielt QA neben Unit-Testing?
Gutes Unit-Testing verschiebt den Schwerpunkt der Arbeit eines QA-Teams. Wenn die Grundlogik bereits abgedeckt ist, finden Tester weniger einfache Fehler, etwa eine falsche Summe oder ein kaputtes Datumsformat. QA-Ingenieure können sich dann auf Probleme konzentrieren, die Unit-Testing nicht sieht und die zwischen den Teilen des Produkts und vor echten Nutzern auftreten:
- Wie die Teile zusammenarbeiten: Integrationstests prüfen die Verbindungen, zum Beispiel ob eine bestätigte Buchung dem Kunden tatsächlich eine E-Mail schickt. Bei Produkten, die an externe Anbieter und Partnerplattformen angebunden sind, decken Systemintegrationstests auch diese Verbindungen ab.
- Ob alte Funktionen noch funktionieren: Regressionstests wiederholen frühere Prüfungen nach jedem Update, weil eine Änderung an einer Stelle eine Funktion an einer anderen beschädigen kann.
- Wie sich das Produkt anfühlt: Manuelle Tests durch einen erfahrenen Spezialisten finden verwirrende Bildschirme und seltsames Verhalten. Dazu gehört auch exploratives Testen, eine freie Untersuchung des Produkts ohne vorbereitetes Skript.
Zusammen mit Unit-Tests ergibt diese Arbeit die Qualitätsprüfung von Software, bei der jede Art von Prüfung Probleme findet, die die anderen übersehen. Unsere Ingenieure setzen bei den Tests an, die Ihre Entwickler bereits geschrieben haben, und bauen darauf automatisierte und manuelle Testabdeckung auf. So wird keine Arbeit doppelt gemacht und nichts rutscht durch.
Sie möchten die Lücken finden, die Ihre Unit-Tests übersehen? Sprechen Sie mit unserem Team.
Häufige Fragen
Ist Unit-Testing dasselbe wie Komponententests?
Unit-Tests und Komponententests werden oft gleichgesetzt, doch das ISTQB-Glossar, das Standardnachschlagewerk für QA-Begriffe, gibt inzwischen jedem Begriff eine eigene Definition. Das kleinste prüfbare Stück eines Programms, meist eine einzelne Funktion, gilt als Unit. Eine Komponente kann größer sein, etwa ein Zahlungsmodul aus vielen kleineren Teilen. Auch dann trennt der Test sie vom Rest des Systems.
Schreibt QA Unit-Tests?
Unit-Testing ist meist Aufgabe der Entwickler, da die Tests im Quellcode des Produkts liegen und nach jeder Änderung erneut laufen. QA-Ingenieure tragen bei, indem sie bestehende Tests auf fehlende Fälle prüfen und testen, was einzelne Funktionen nicht zeigen können, etwa eine unterbrochene Verbindung zwischen zwei Systemen. In manchen Projekten schreiben auch Automatisierungsspezialisten mit Codezugriff diese Tests, wenn die Entwickler wenig Zeit haben.
Wie viel Testabdeckung durch Unit-Tests reicht aus?
Es gibt keine Abdeckungszahl, die für alle Produkte passt. Wer 100 % anstrebt, muss jede Codezeile in mindestens einem Test ausführen lassen. Dieses Ziel lohnt sich selten, weil Aufwand in trivialen Code fließt, nur um die Zahl zu bewegen. Ein besseres Ziel für Unit-Testing ist eine nahezu vollständige Abdeckung der Hochrisikobereiche wie Zahlungen, Preisberechnung, Anmeldung und gespeicherte Kundendaten. Regelmäßige Reviews sollten dann bestätigen, was jeder Test tatsächlich prüft.
Kann KI Unit-Tests schreiben?
Ja, KI kann Unit-Tests generieren und repetitive Arbeit gut erledigen, etwa Dutzende Eingabevarianten für eine Funktion auflisten. Die Schwachstelle ist die geschäftliche Absicht. Ein KI-Modell nimmt bestehenden Code für bare Münze, und wenn darin ein Bug steckt, kann der generierte Test diesen Bug als erwartetes Verhalten festschreiben. Jeder KI-generierte Test braucht weiterhin einen Menschen, der bestätigt, dass er dem entspricht, was das Unternehmen will.
Sehen Sie, wie wir ChitChat geholfen haben, über 200 Bugs auf 24 echten Geräten zu beheben, vor der ersten Store-Veröffentlichung
