Flexibel und pflegeleicht: Testing ohne Mocks

Robuste, automatisierte Tests sind feste Bestandteile der agilen Softwareentwicklung. Da Anforderungen und Rahmenbedingungen sich stetig ändern, müssen Entwicklerinnen und Entwickler kontinuierlich in der Lage sein, ihre Architektur anzupassen. Ihr Code muss wachsen und sich weiterentwickeln können. Sie müssen laufend bestehende Features erweitern, anpassen, umsortieren, zusammenführen oder aufteilen. Dazu benötigen sie die Unterstützung einer schnellen, verlässlichen und robusten Testsuite, die bestehende Funktionen der Software nicht beeinträchtigt.

Auf Mocks basierende Tests verursachen häufig zusätzlichen Pflegeaufwand beim Refaktorieren, also Änderungen an der Codestruktur, die die Arbeit mit dem Code insgesamt vereinfachen, das Verhalten des Systems aber nicht verändern. Die Art und Weise, wie Mocks in der Praxis meist zum Einsatz kommen, führt zu einer Kopplung von Tests und Implementierungsdetails. Änderungen an diesen Details erfordern Anpassungen der Tests, was zulasten der Entwicklungsgeschwindigkeit geht.

Dieser Artikel zeigt auf, welche Kompromisse mit auf Mocks basierenden Tests verbunden sind und stellt mit dem Nullable-Entwurfsmuster von James Shore eine Alternative vor.

Isolierte, interaktionsbasierte Tests

Mock-Objekte oder kurz Mocks (englisch für „Attrappe“) sind eine Unterkategorie der Test-Doubles, die in Unit Tests als Platzhalter für Produktionsobjekte dienen. Der Begriff Test-Double ist angelehnt an das Stunt-Double in Filmen. Weitere Arten von Test-Doubles sind Stubs, Spies oder Fakes.

Mocks zeichnen während eines Testlaufs auf, wie die Software mit ihnen interagiert: Welche ihrer Methoden ruft die Anwendung in welcher Reihenfolge und mit welchen Argumenten auf? Anschließend verifiziert der Unit-Test, ob die beobachteten Interaktionen mit den erwarteten übereinstimmen. Auf diese Weise werden die Interaktionen zwischen den Objekten zu einem integralen Bestandteil der Implementierung und der Tests. Diese Art von Tests wird als Interaction-based bezeichnet.

Gleichzeitig isolieren Mocks das zu testende Objekt von seinen Abhängigkeiten. Während des Tests wird also nur der Code eines einzelnen Objekts ausgeführt, während alle Interaktionspartner durch Mocks ersetzt werden. Tests, die Objekte in Isolation testen, nennt man solitary.

Auch wenn Solitary Interaction-based Tests ihre Vorzüge haben und sich im Laufe der Zeit zum Standard entwickelt haben, sind sie nicht frei von Nachteilen. Dass Tests an die Interaktionen zwischen Objekten gekoppelt sind, erschwert Refaktorierungen. Diese sind jedoch ein unverzichtbares Werkzeug, um die Qualität der Codebasis dauerhaft aufrechtzuerhalten.

Refaktorierungen, die die Interaktionen zwischen Objekten verändern, können zu False Positives führen: Tests schlagen fehl, obwohl das Programm als Ganzes keine Fehler enthält. Lediglich die Objektinteraktionen weichen von den Erwartungen der Tests ab. Eine Suite aus Interaction-based Tests macht die Codebasis dadurch insgesamt weniger flexibel, da die Tests die Implementierungsdetails fixieren.

Zudem kann es vorkommen, dass Solitary Tests Fehler nicht erkennen, wenn zwar alle Objekte in Isolation erwartungsgemäß arbeiten, es aber im Zusammenspiel der Objekte zu unerwünschtem Verhalten kommt. Um dem vorzubeugen, sind neben den Unit Tests zusätzliche Integrationstests erforderlich, die gezielt das Zusammenspiel mehrerer Objekte testen.

Eine Alternative stellen Sociable, State-based Tests dar.

Echte Abhängigkeiten und sichtbares Verhalten

In Sociable Tests interagiert das zu testende Objekt nicht mit Test-Doubles, sondern mit den echten Abhängigkeiten, die auch im Produktivbetrieb existieren. Fehler, die durch die Interaktion zwischen den Objekten entstehen, fallen im Test sofort auf. Separate Integrationstests sind nicht erforderlich.

State-based Tests verifizieren das sichtbare Verhalten von Objekten und ignorieren die darunter liegenden Interaktionen. Diese Tests reagieren daher sehr viel robuster gegenüber Refactorings, da sie sich nur für das Endergebnis interessieren und nicht für die Implementierungsdetails.

Der Elefant im Raum

Die echten Produktionsobjekte in den Tests zu verwenden, statt sie durch Mocks zu ersetzen, führt zunächst zu einem Problem: Der zu testende Code muss mit APIs, Datenbanken oder dem Dateisystem kommunizieren. Diese Nebenwirkungen (Side Effects) würden zu nicht deterministischen Tests führen, da sie vom globalen Zustand abhängig sind, unter anderem von Drittsystemen. So könnte etwa ein Test fehlschlagen, weil eine Fremd-API mit anderen Daten antwortet, als es der Test erwartet.

Ein weiteres Problem sind die Auswirkungen, die API-Aufrufe haben können. Dass jede Ausführung der Warenkorbtests eine Kreditkarte belastet, ist nicht wünschenswert. Darüber hinaus muss es möglich sein, zu testen, wie sich ein Programm verhält, wenn eine Dritt-API mit unterschiedlichen Formaten, mit Fehlern oder gar nicht antwortet. Und schließlich verlangsamt die API-Anbindung die Tests.

Integrationstests sind zwar für den Übergang des zu implementierenden Systems mit der Außenwelt notwendig, aber die Nebenwirkungen sind für die Tests innerhalb des Systems unerwünscht.