Im Bereich der Softwareentwicklung spielt Testing eine zentrale Rolle, insbesondere bei komplexen Systemen und langlebigen Anwendungen. In der iOS-Entwicklung mit Swift begegnet man oft Herausforderungen rund um die Implementierung und Anwendung von Testmethoden. Dabei fällt häufig das Schlagwort Mocking – das Erzeugen von Platzhalterobjekten, um Abhängigkeiten zu simulieren und einzelne Komponenten isoliert testen zu können. Doch ist exzessives Mocking wirklich der Königsweg? Oder gibt es Alternativen, die Tests nicht nur ergebnisorientierter, sondern auch effizienter gestalten? Ein neuer Denkansatz regt dazu an, so wenig wie möglich zu mocken, stattdessen reale Implementierungen zu testen und Dependency Injection nur an den Rändern einzusetzen. Diese Philosophie führt zu klareren Tests, reduziertem Wartungsaufwand und einem besseren Bezug zur tatsächlichen Produktivumgebung.
Das Thema testbarer Code wird in Swift durch die existierenden Patterns und Frameworks wie Dependency Injection (DI) und Protokollorientierte Programmierung geprägt. Viele Entwickler setzen auf umfangreiche Protokollhierarchien mit zugehörigen Mocks, um alle möglichen API-Varianten und Rückgabewerte abzudecken. Leider führt das mitunter dazu, dass sich Mocks weit vom produktiven Verhalten entfernen oder sogar – entgegen ihrer Aufgabe – Fehler verstecken. Dies resultiert in einer Diskrepanz zwischen Testcode und Realität. Tests gelten somit als „grün“, obwohl reale Nutzer auf unerwartete Fälle stoßen. In diesem Kontext stellt sich die Frage: Wie lassen sich Tests bauen, die nah am echten Verhalten bleiben und dennoch leicht wartbar sind?
Eine Lösung liegt im Prinzip des sogenannten "Self-Mocking", bei dem die eigentliche Implementierung soweit modular und konfigurierbar aufgebaut wird, dass sie im Testfall einfach die produktiven Seiteneffekte ausschalten kann, ohne eine komplett neue Mock-Implementierung benötigt zu werden. So kann die eigentliche Logik unverändert bleiben und muss nicht doppelt gepflegt werden. Ein Beispiel aus der Praxis ist ein Keychain-Wrapper in Swift, der die komplexe Nutzung der iOS Keychain abstrahiert und gleichzeitig die Speicherverwaltung in einer Cache-Schicht vereinfacht. Der vorgestellte Keychain-Wrapper arbeitet als Actor mit einem in-memory Cache und der eigentlichen Speicherimplementierung für den System-Keychain-Zugriff. In Tests lässt sich dieser Speicher leicht gegen eine leere, optionale Implementierung austauschen. Sobald diese Storage-Variable auf nil gesetzt wird, agiert die Komponente intern rein lokal und verzichtet auf echte Schlüsselbund-Zugriffe.
Damit entsteht automatisch ein Mock-Verhalten, ohne dass ein separates Mock-Objekt oder eine überladene Protokollhierarchie benötigt wird. Die Vorteile liegen auf der Hand: Die Logik für Kodierung, Zwischenspeicherung und Transaktionen wird nur einmal gepflegt, Tests spiegeln das reale Verhalten wider, und der Fokus liegt klar auf den Varianten, die tatsächlich eine Abweichung im Speicherverhalten aufweisen. Ein häufiges Missverständnis in der Swift-Welt besteht darin, dass Protokolle als abstrakte Klassenersatz dienen sollen. Dies führt dazu, dass Entwickler komplette Schnittstellen duplizieren, inklusive aller Methoden, die sich in Mocks nicht variieren oder anders implementieren. Dieses Vorgehen erhöht die Komplexität von Tests, da jede Änderung am Interface zwangsläufig auch die Mocks betrifft. Außerdem ist das Schreiben und Warten eines solchen Mocks zeitintensiv, und er bildet häufig eine inkorrekte Abstraktion, da der Mock nicht das echte Systemverhalten vollständig abbildet.
Wesentlich sinnvoller ist es, einen schlankeren Protokollansatz zu wählen, der nur die fundamentalen Elemente umfasst, deren Implementierung variieren könnte – im Beispiel sind dies nur Datenoperationen wie Lesen, Schreiben, Entfernen und Zurücksetzen. Die übrigen Funktionalitäten, wie das Kodieren und Dekodieren von Strings, JSON-Objekten oder einfachen Datentypen, lassen sich in Protokollerweiterungen implementieren und werden von der realen Implementierung sowie vom Mock gleich genutzt. So ist gewährleistet, dass Änderungen in der Kodierungslogik automatisch in Tests abgebildet sind und eventuelle Fehler früh auffallen. Ein weiterer Vorteil dieser Herangehensweise ist, dass Tests nicht gegen Mocks „testen“, sondern real existierenden oder sehr nahe am Produktivsystem angesiedelten Code überprüfen. Dies erhöht die Aussagekraft der Tests enorm.
Insbesondere in Umgebungen wie iOS, wo manche APIs, etwa der Zugriff auf den System-Keychain, nicht ohne entsprechende Berechtigungen oder in bestimmten Kontexten (z. B. SPM-Pakete unter iOS) verwendet werden können, ist dies ein entscheidender Vorteil. Anstatt komplette Mock-Frameworks einzurichten und zu warten, kann mit Hilfe von optionalen Storage-Schnittstellen oder Zustandsparametern schnell und effektiv zwischen Produktion und Testbetrieb umgeschaltet werden. Diese Strategie fördert nicht nur die Entwicklerproduktivität, sondern wirkt sich direkt positiv auf die Codequalität aus. Indem die produktive und die Testimplementierung nahe aneinander bleiben, sinkt die Wahrscheinlichkeit, dass neue Features oder Bugfixes in Tests übersehen werden. Die Realität und der Test stimmen überein – und das ist das Ziel jeder Teststrategie. Es lohnt sich außerdem, den Ansatz unter dem Gesichtspunkt von YAGNI (You Aren’t Gonna Need It) zu betrachten.
Oft führen Entwickler dazu, Kontroll- und Abstraktionsschichten zu entwickeln, die Features vorsehen, die erst später gebraucht werden oder gar nicht. Dies macht den Code unnötig kompliziert. Die gezeigte Keychain-Implementierung reflektiert tatsächlich eine Evolution im Laufe der Zeit – beginnend mit einfachen Data-Operationen, über String- und JSON-Support bis hin zu vielfältigen Typen wie Bool oder Int. Die Integration von Codable-Unterstützung erfolgte erst später, was wiederum neue Herausforderungen für die Synchronisation von Mock und Produktcode brachte. Solche Veränderungen nach dem Prinzip „Man baut nur Mindestfunktionalität und erweitert sie bei Bedarf“ minimieren technologische Komplexität und erleichtern sowohl Testen als auch Wartung. Die Philosophie, die hinter diesem Ansatz steht, fordert Entwickler heraus, neu über die Rolle von Typen und Protokollen im Testkontext nachzudenken.
Anstatt Tests mit umfangreichen und vollständigen Mocks zu überfrachten, beschränkt man sich auf klare, minimalistische Schnittstellen, die nur das Verhalten abbilden, welches auch tatsächlich variiert oder von außen beeinflusst wird. Die Geschäftslogik oder Kodierungsdetails werden nicht noch einmal simuliert, sondern in Protokollerweiterungen geteilt und somit konsistent gehalten. So entsteht eine saubere Trennung zwischen variablen und stabilen Komponententeilen. Es ist wichtig zu erwähnen, dass diese Methodik nicht das Ziel verfolgt, komplett auf Mocking zu verzichten. Gerade in Fällen wie dem System-Keychain-Zugriff, der sich ohne passende Entitlements nicht direkt testen lässt, ist eine Art Mocking nötig. Allerdings sollten diese Mocks schlank und fokussiert gestaltet sein, um möglichst wenig Wartungsaufwand und möglichst echte Verhaltenstreue zu gewährleisten.
Die Entkopplung der Speicherschicht in eine optionale Storage-Komponente ist genau so ein Werkzeug: Es erlaubt Tests ohne Systemabhängigkeiten, ohne das Verhalten umfassend neu zu schreiben. Diese Überlegungen werden noch ergänzt von philosophischen Aspekten zum Thema Testing generell. Tests sollten nicht um der Coverage oder reinen Testmenge willen geschrieben werden, sondern mit einem klaren Ziel vor Augen: Die Qualität der Software und die Sicherheit, dass sie im Produktivbetrieb tut, was sie soll. Dies bedeutet auch, dass eine hohe Abstraktion oder eine riesige Anzahl an Tests nicht automatisch gut sind. Tests müssen sinnvoll, überschaubar und vor allem realitätsnah sein. Der Blick auf die Implementierung eines Keychain-Wrappers zeigt anschaulich, dass es möglich ist, komplexe problematische Legacy-Interfaces mit vielen Unterschieden in der Praxis so zu gestalten, dass Tests diese Nuanzen verstehen und abdecken, ohne dass sich die Testwelt immer weiter von der Realität entfernt.
Diese Herangehensweise lässt sich auf viele andere Bereiche der Softwareentwicklung übertragen, in denen vermeintlich „unmockbare“ oder schwer testbare Komponenten eine Herausforderung darstellen. Abschließend bietet das Prinzip des minimalen Mockings, des Testens am Rand und der Konzentration auf realen Code einen frischen, pragmatischen Blick auf Softwaretests in Swift und iOS. Es erfordert ein Umdenken, vor allem bei Gewohnheiten rund um Protocol-Oriented Programming und Mock-basierte Teststrategien. Doch wer sich darauf einlässt, kann nachhaltigere, lesbarere und einfachere Teststrukturen schaffen, die enger am echten Verhalten des Produkts sind und so langfristig zu stabileren, zuverlässigen Anwendungen führen.
Für Entwickler, die mit den Herausforderungen des Testens in der iOS-Landschaft und Swift konfrontiert sind oder bisher hauptsächlich mit klassischen Mock-Frameworks und umfangreichen Protokollen gearbeitet haben, lohnt sich eine intensive Auseinandersetzung mit diesem Paradigma. Es ist nicht nur eine technische Empfehlung, sondern auch eine Einladung, die Philosophie hinter Testing neu zu überdenken und pragmatischer an diese wichtige Aufgabe heranzugehen.
