Antwort.

Automatisierte Tests werden in Unit-Tests, Integrationstests und End-to-End (E2E) Tests unterteilt, um die Überprüfung des Systems auf verschiedenen Ebenen umfassend abzudecken.

Geschichte der Frage: Diese Klassifizierung entstand aus der Notwendigkeit, Anwendungen sowohl in Teilen als auch im Ganzen zu testen. Daher werden Testschichten unterschieden:

spezifische Funktion (Unit)
Interaktion der Teile (Integration)
das gesamte System, das sowohl für den Benutzer als auch für andere (E2E) funktioniert.

Problem: Fehler treten häufig nicht nur in der Logik einer einzelnen Methode auf, sondern auch an den Schnittstellen von Komponenten oder beim "echten" Start des gesamten Systems mit externen Diensten. Wenn alles in einen Topf geworfen wird, ist es schwierig, einen Bug schnell zu lokalisieren oder zu verstehen, wo genau er aufgetreten ist.

Lösung:

Unit-Tests prüfen isolierten Code, in der Regel auf der Funktions- oder einfacheren Klassenebene. In erweiterten Fällen werden Mocks und Stubs verwendet.
Integrationstests verbinden mehrere Komponenten (z. B. Modul und DB), um zu sehen, wie sie zusammenarbeiten.
End-to-End-Tests (E2E) simulieren Benutzerszenarien – den gesamten Weg "von der Schaltfläche bis zum Ergebnis".

Es ist lebensnotwendig, Testtypen zu unterscheiden, um:

Die Kosten für die Wartung zu minimieren (E2E-Tests sind teuer)
Schnelles Feedback zu erhalten (Unit-Tests sind blitzschnell)
Die Anzahl falscher Positiver zu reduzieren

Wichtige Merkmale:

Eine richtige Verteilung der Tests hilft, einen zuverlässigen "pyramidalen" Ansatz (Testpyramide) zu entwickeln.
Vermischung von Teststilen führt zu Problemen bei der Lokalisierung von Bugs.
Ein klares Verständnis der Funktion jedes Schicht führt zu maximaler Effizienz.

Fangfragen.

Kann man Integrationstests einfach als "große" Unit-Tests betrachten?

Nein, Integrationstests überprüfen die Funktionsweise mehrerer Komponenten im Verbund und nicht nur einzelner Funktionen. Dabei ist es nicht immer möglich, Mocks zu verwenden – reale Dienste interagieren miteinander.

Müssen alle Tests End-to-End (E2E) sein?

Nein, das ist ein teurer und komplexer Ansatz. E2E-Tests sind nur für kritische Benutzerszenarien erforderlich; die meisten Logiken werden mit anderen Tests abgedeckt.

Sind Unit-Tests immer schnell?

Nicht immer. Es kann sein, dass isolierter Code nicht erreicht werden kann oder der Methode komplexe externe Ressourcen abhängen. In diesem Fall hört der Test auf, ein Unit-Test zu sein.

Typische Fehler und Anti-Muster

Alle Tests werden nur als E2E geschrieben, das Feedback erfolgt extrem langsam.
Verwirrung in den Schichten: Unit-Tests greifen auf die DB oder API zu, während E2E-Tests auf Mocks basieren.
Es bleiben nur Unit-Tests übrig – problematische Bugs an den Schnittstellen von Komponenten werden nicht erfasst.

Beispiel aus dem Leben

Negativer Fall

Im Unternehmen wurde die Hauptfunktionalität nur mit E2E-Tests abgedeckt – jede Änderung wurde nachts geprüft, die Tests fielen instabil aus, Bugs wurden spät entdeckt.

Vorteile:

Echte Benutzerszenarien sind abgedeckt.

Nachteile:

Langsame Rückmeldung.
Lange Analysen der Ursachen von Ausfällen.
Viele falsche Positiv.

Positiver Fall

Das Team baute eine Testpyramide auf: unten – Unit-Tests, in der Mitte – Integrationstests, oben – nur die wichtigsten E2E.