Test mit gefälschten Daten unter iOS

Um qualitativ hochwertige Software bereitzustellen und Regressionen zu vermeiden, ist die Implementierung von Unit-Tests ein Muss für jede iOS-Anwendung.
Das Verspotten von Objekten ist eine Methode beim Komponententest, bei der gefälschte Objekte unter Verwendung derselben APIs wie die echten erstellt werden.
Dieser Artikel soll Ihnen die Best Practices für die Verwendung gefälschter Daten und das Schreiben von Komponententests für die häufigsten Szenarien in iOS-Apps vermitteln.

Wenn wir Unit-Tests schreiben, sollten wir immer vermeiden, die realen Daten des Anwendungsziels zu ändern, und stattdessen falsche Daten nur zu Testzwecken verwenden.

In den folgenden Abschnitten wird erläutert, wie Sie Tests mit gefälschten Daten für häufig verwendete iOS-APIs schreiben.

Benutzervorgaben

In der Softwareentwicklung ist es immer ratsam, Abhängigkeiten der Objekte zu reduzieren. Abhängigkeiten sollten im besten Fall in die Klassen eingefügt werden, die sie verwenden.

Wenn wir jedoch die realen iOS-Entwicklungsszenarien überprüfen, verwendet fast jedes Projekt UserDefaults, indem es die API direkt aufruft, um Daten zu speichern oder abzurufen.

Daher werden wir versuchen, eine praktische Lösung zum Testen von UserDefaults anzubieten, anstatt die API mit Protokollen zu abstrahieren.

In UserDefaults können zwei neue Funktionen erstellt werden

Es ist immer eine gute Praxis, die Anwendungsdaten des Unit-Test-Ziels nicht zu ändern. Daher sollten wir einen anderen Ort zum Speichern von Benutzerdaten für unser Test-Ziel erstellen.

In diesem Fall initialisieren wir ein neues Objekt von UserDefaults mit suiteName - testDefaults, das von den Standard-UserDefaults völlig unabhängig ist.

Versuchen wir, einen einfachen Test zu schreiben, der UserDefaults verwendet

Da diese Daten im Grunde genommen nur zum Testen verwendet werden, sollten wir vermeiden, dass diese Daten in unseren Anwendungsdateien hängen bleiben. Daher erstellen wir eine Funktion, die dafür verantwortlich ist, diesen Speicher nach Abschluss des Tests zu löschen.

Der beste Ort zum Löschen dieser Daten ist natürlich die tearDown-Funktion in unserer Unit-Test-Klasse.

Singelton-Objekte

Singletons Objects werden unter iOS häufig auf vielen APIs verwendet. Sie finden sie unter NSFileManager, NSApplication, UIApplication und an vielen anderen Orten.

Für iOS-Entwickler ist es nützlich zu wissen, wie man Singletons testet.

In unserem Beispiel verwenden wir das iAd-Framework von apple. Wir werden eine Datei erstellen, um eine lokale JSON-Antwort anstelle von echten Daten zu erhalten, wenn Details zur Anzeigenzuordnung angefordert werden.

Ein nettes Feature in iOS ist, dass wir mit Erweiterungen in swift nicht nur neue Funktionen für eine vordefinierte API hinzufügen, sondern sie auch an unsere eigenen benutzerdefinierten Protokolle anpassen können.

Definieren wir ein AdvertismentClient-Protokoll

Danach passen wir uns wie folgt standardmäßig an dieses Protokoll an: ADClient und unser gefälschter Werbeclient

Wir ändern dann die Abhängigkeit zu einem von beiden

private var adClient: AdvertismentClient = ADClient.shared ()

oder

private var adClient: AdvertismentClient = MockAdClient ()

und benutze es wie folgt

Auf diese Weise können wir leicht entscheiden, wann echte Daten verwendet werden sollen und wann die Daten getestet werden sollen, abhängig davon, ob wir Unit-Tests durchführen oder die API von unserem Live-Anwendungsziel aus aufrufen.

Kerndatei

Core-Daten werden in iOS immer noch häufig zum Zwischenspeichern von Daten verwendet. Das Testen von Core-Datenelementen kann schwierig sein. Im Folgenden wird eine bewährte Methode zum Organisieren von Core Data Services und zum Fälschen von Daten erläutert.

Im Allgemeinen ist es in den meisten Fällen immer gut, eine Serviceklasse zu erstellen, die für das Abrufen und Schreiben bestimmter Daten in die Datenbank verantwortlich ist, anstatt den Kerndatencode im gesamten Projekt zu verwenden.

Dies hat hauptsächlich zwei Vorteile:

  • Es entkoppelt Sie von der zugrunde liegenden Datenbank, die verwendet wird. Wenn Sie die Kerndaten in Zukunft durch eine andere Datenbank ersetzen möchten, müssen Sie Änderungen nur in einer Klasse vornehmen.
  • Auf diese Weise können wir leicht entscheiden, welcher CoreDataStack verwendet werden soll oder welche anderen Einstellungen wir in einem anderen Framework benötigen.

Wir werden ein CoreDataStack-Protokoll erstellen und danach zwei CoreDataStack-Protokolle, die diesem Protokoll entsprechen, ein MainCoreDataStack-Protokoll und ein MockCoreDataStack-Protokoll.

Unser DatabaseService kann dann von beiden initialisiert werden, je nachdem, ob wir ihn auf unserem Anwendungsziel oder auf unserem Unit-Testing-Ziel verwenden.

Unser Haupt-Core-Datenstack wird wie folgt voreingestellt

Beim Testen von Einheiten sollten wir immer vermeiden, den Status aktueller "realer" Objekte zu ändern, wenn wir sie testen.

Wenn wir also gefälschte Kerndatenentitäten erstellen möchten, sollten wir einen separaten permanenten Speicher haben und die speicherinterne Konfiguration verwenden, damit die vorgenommenen Änderungen nicht auf der Festplatte gespeichert werden und sie vollständig von den aktuell persistierten Daten getrennt werden.

Jetzt können wir unseren Datenbankservice erstellen, der standardmäßig mit MainCoreDataStack initialisiert wird.

Und in unserer Testklasse können wir es mit dem gefälschten Datenstapel initialisieren

Wir können jetzt ein paar einfache Tests wie folgt schreiben:

Mit diesem Ansatz können wir unseren DatabaseService problemlos testen, ohne dass sich dies auf die vom Anwendungsziel gespeicherten Daten auswirkt.

Netzwerkanfragen

Beim Testen der Netzwerkschicht können wir den protokollorientierten Ansatz verwenden, um ein Protokoll zu erstellen und es sowohl mit realem NetworkService als auch mit MockNetworkService anzupassen. Anschließend können Abhängigkeiten entweder mit realem oder mit verspottetem Service eingefügt werden.

In diesem Artikel werden wir allerdings eine wirklich nette Open-Source-Bibliothek namens OHHTTPStubs verwenden, die noch besser mit Spott und Stubbing umgehen kann.

Das Gute an dieser Bibliothek ist, dass sie hervorragend mit der berühmten iOS-Netzwerkbibliothek Alamofire zusammenarbeitet.

Stubbing-Netzwerkanfragen sind ganz einfach. Mit OHHTTPStubs können Sie jede Antwort für einen bestimmten Pfad oder Host ersetzen, indem Sie eine benutzerdefinierte Antwort mit einem Wörterbuch versehen.

Danach gibt jede Anforderung, die von der App an die folgende URL gesendet wird, stattdessen unsere benutzerdefinierte Antwort zurück.

let tasksURL = URL (Zeichenfolge: "https://jsonplaceholder.typicode.com/todos")!

Das Schöne an benutzerdefinierten Antworten ist auch, dass Sie auf einfache Weise testen können, ob Fehler- und Randfälle korrekt behandelt werden, indem Sie einfach einen Fehler in der Antwort zurückgeben.

Das manuelle Erstellen des Wörterbuchs für die Antwort ist eine großartige Funktion. Wenn wir jedoch große JSON-Daten mit vielen Eigenschaften zurückgeben möchten, kann dies in unseren Testklassen zu Problemen führen und kaum noch zu warten sein.

In diesen Fällen können wir eine JSON-Datei verwenden, um die Antwort wie folgt zu stoppen.

Jedes Mal, wenn unsere App die Anfrage sendet, erhalten wir die Antwort von der Datei myResponse.json, die wir in unseren Dateien gespeichert haben.

Wir sollten uns jedoch daran erinnern, vertrauliche Informationen nicht in diesen JSON-Dateien zu speichern, da diese Dateien, wenn wir sie zusammen mit der Anwendung versenden, problemlos angezeigt werden können.

Weitere Informationen finden Sie in meinem Artikel zum Thema Sicherheit.

Abschließend

Unit-Tests unserer Anwendung sind ein Muss, wenn wir eine Regression so weit wie möglich vermeiden und auch versuchen möchten, eine fehlerfreie Anwendung bereitzustellen.

In diesem Artikel wurde erläutert, wie Sie Tests für häufige Fälle durchführen können, die während der iOS-Entwicklung auftreten.

Wir diskutierten, wie UserDefaults, Singeltons, Core-Daten und Netzwerkanforderungen getestet werden.

Wenn dir dieser Artikel gefallen hat, klatsche auf jeden Fall, um deine Unterstützung zu zeigen.

Folgen Sie mir, um viele weitere Artikel zu lesen, die Ihre iOS-Entwicklerfähigkeiten auf eine neue Ebene heben.

Wenn Sie Fragen oder Kommentare haben, können Sie hier eine Nachricht hinterlassen oder eine E-Mail an arlindaliu.dev@gmail.com senden.