Antwort.

Die Automatisierung von Tests der Geschäftslogik in komplexen Anwendungen hat eine lange Geschichte, die mit den ersten Skripten zur Überprüfung von Validierern begann und bis zu modernen Mikrodiensten reicht. Mit der Zunahme der Komplexität von Architekturen (Monolith, SOA, Mikro- und Makrodienste) entstand das Problem, dass Änderungen auf einer Ebene der Architektur oft Tests auf anderen Ebenen brechen.

Das Problem besteht darin, dass man Tests schreiben muss, die resistent gegen die Neugestaltung der Interaktion zwischen den Schichten der Anwendung sind: Änderungen der Verträge, Datenstrukturen und Geschäftsprozesse. Oft binden sich Tests an Implementierungsdetails, wodurch sie "zerbrechlich" und schwer wartbar werden.

Die Lösung ist, Tests nach dem Prinzip des "schwarzen Kastens" zu gestalten, die sich auf Eingaben/Ausgaben konzentrieren, Schichten der Abstraktion für den Zugriff auf die Entitäten des Systems (zum Beispiel Service Layer und Domain Layer in der Architektur) zu verwenden. Es ist wichtig, die Geschäftslogik von infrastrukturellen Details zu trennen und Mocks/Stubs für externe Abhängigkeiten zu verwenden, um Isolation und Stabilität der Tests zu gewährleisten.

Wesentliche Merkmale:

Fokussierung auf das Testen von Verträgen: Überprüfung von Geschäfts-Invarianten unabhängig von internen Implementierungen.
Verwendung von Abstraktionsschichten für den Zugriff auf die Logik (z. B. Application Service → Domain Service → Repository).
Implementierung von MVP/Mocks/Stubs für Reproduzierbarkeit und Isolation der Testumgebung.

Fangfragen.

Worin besteht der Unterschied zwischen dem Testen von Geschäftslogik über die UI-Schicht und dem Testen über die API/Domain Layer?

UI-Tests sind oft weniger stabil gegenüber Änderungen, da bereits geringste Änderungen an der Benutzeroberfläche zu Testfehlern führen. Tests über API oder Domain Layer sind weniger vom Frontend abhängig und isolieren die Überprüfung von Geschäftsvorschriften erfolgreicher.

Muss man alle Abhängigkeiten der Geschäftslogik für ihre Tests mocken?

Nein! Es ist nicht sinnvoll, da zu mocken, was in der Testumgebung realisiert werden kann (z. B. leichtgewichtiger Speicher anstelle von DB). Mocks sind für komplexe, teure oder externe Abhängigkeiten notwendig. Vollständiges Mocking kann zu "fiktiven" Tests führen, die nicht die realen Szenarien widerspiegeln.

Reicht es aus, nur positive Szenarien für die Geschäftslogik zu testen?

Nein! Es ist wichtig, alle Grenzfälle und negativen Szenarien abzudecken, da sonst kritische Fehler unentdeckt bleiben, was die Hauptgeschäftsprozesse anfällig macht.

Typische Fehler und Antipatterns

Bindung von Tests an interne Objekte/Datenstrukturen, zerbrechliche Selektoren.
Fehlende negative/alternative Pfade.
Viele redundante Tests mit geringfügigen Variationen.

Beispiel aus dem Leben

Negativer Fall

Im Projekt wurde die Geschäftslogik nur über UI Selenium-Tests getestet, die direkt mit Schaltflächen und Formularen interagieren. Jeder Refactoring des Frontends führte zu massiven Ausfällen der automatisierten Tests.

Vorteile:

Schnelle anfängliche Abdeckung aller Funktionalitäten
Leicht verständlich für das Management

Nachteile:

Zerbrechlichkeit: kleinste Änderungen in der UI brechen alles
Langsame, instabile Tests, schwer wartbar

Positiver Fall

Im Projekt wurde eine Schnittstelle für API- und Unit-Tests implementiert. Die UI deckte nur kritische Pfade ab, die gesamte andere Validierung erfolgte über die Service-Ebene mit Mocking teurer Dienste.