[Ios] Auf der Suche nach einem anständigen Schema zur Implementierung von Akzeptanztestumgebungen mit nativen Objective-C & Mac-Technologien


Answers

Question

Hintergrund

Ich bin auf der Suche nach einer Möglichkeit, ein ähnliches Schema wie die Frank-Bibliothek zu implementieren, um "automatisierte Akzeptanztests für native iOS-Apps" zu implementieren, aber ich möchte, dass dieses Schema auf nativen iOS / MacOSX-Technologien beruht. Sorry für die folgende TLDR aber es verdient eine ausführliche Erklärung.

1. Hier ist ein kurzer Überblick, wie Frank arbeitet:

Es hat Client- und Server-Teile.

Der Serverteil ist in eine Anwendung eingebettet, für die wir Abnahmetests durchführen möchten. Frank-Tutorials zeigen uns, wie Sie ein doppeltes Ziel des Hauptziels einer App erstellen und den Frank-HTTP-Server darin einbetten.

Clientpart - ist hauptsächlich eine Gurke , die reine Textszenarios ausführt: Jedes Szenario enthält Anweisungen, die für eine App ausgeführt werden sollen (Textfeld ausfüllen, Schaltfläche berühren, sicherstellen, dass ein bestimmtes Element auf einer Seite vorhanden ist usw.). Jedes Szenario startet auch seine eigene App-Instanz, indem es bei jedem Eintritt in ein neues Szenario einen neuen Status liefert.

Client (Cucumber- und Ruby-to-Objective-C-Bridge) kommuniziert mit dem Server (HTTP-Server, der in eine App eingebettet ist) über das HTTP-Protokoll. Es verwendet spezielle Konventionen, so dass der Client dem Server mitteilen kann, was eine App tun soll, damit das spezifische Szenario ausgeführt werden kann.

2. Kürzlich habe ich den folgenden Artikel des Autors von Frank Pete Hodgson gefunden:

http://blog.thepete.net/blog/2012/11/18/writing-ios-acceptance-tests-using-kiwi/

Darin schlägt er einfachere Abnahmetests für Entwickler vor, die sich nicht auf externe Tools wie Cucumber und Ruby verlassen wollen. Lassen Sie mich den Autor selbst zitieren:

Bevor ich anfange, möchte ich klarstellen, dass ich persönlich diesen Ansatz nicht für Abnahmetests verwende. Ich bevorzuge es, eine höhere Sprache wie Ruby zu benutzen, um diese Art von Tests zu schreiben. Der Testcode ist viel weniger Arbeit und viel expressiver, vorausgesetzt, Sie fühlen sich in Ruby wohl. Und deshalb wollte ich dieses Experiment ausprobieren. Ich habe im Laufe der Zeit mit etlichen iOS-Entwicklern gesprochen, die sich nicht wohl fühlen, Tests in Ruby zu schreiben. Sie sind in Objective-C besser als alles andere und möchten ihre Tests in derselben Sprache schreiben, die sie für ihren Produktionscode verwenden. Meinetwegen.

Dieser Blog-Beitrag hat mich dazu inspiriert, schnell mein eigenes, sehr primitives Tool zu erstellen , das genau das tut, was Pete in seinem Blogpost beschrieben hat: NativeAutomation .

In der Tat, wie es von Pete beschrieben wurde, ist es möglich, Akzeptanztests durchzuführen, indem nur ein Kiwi / PublicAutomation-Setup verwendet wird, das in einem einfachen OCTests-Ziel platziert wird. Ich mochte es wirklich, weil:

  • Es ist nur reines C / Objective-C. Es war sehr einfach, ein paar C-Helfer zu bauen, die wie Capybara- Helfer aussehen:

tapButtonWithTitle, fillTextFieldWithPlaceholder, hasLabelWithTitle und so weiter ...

  • Es benötigt keine externen Tools und Sprachen: keine Notwendigkeit in Cucumber / Ruby oder irgendetwas anderes. NativeAutomation selbst verwendet nur PublicAutomation , die Frank ebenfalls verwendet. PublicAutomation wird benötigt, um Benutzerinteraktionen auf dem Bildschirm einer App zu simulieren: Berührungen, Füllungen, Gesten ...

  • Es ist sehr praktisch, diese Tests direkt von Xcode aus durchzuführen, indem Sie einfach ein Cocoa Unit Tests-Bundle ausführen. (Obwohl Kommandozeilen-Builds auch einfach sind).

Problem

Das Problem beim Kiwi/PublicAutomation Ansatz ist, dass die gesamte Testsuite in das Paket der App eingebettet ist. Dies bedeutet, dass nach dem Ausführen jedes Szenarios die Anwendung nicht zurückgesetzt werden kann, um sie in einen neuen Status zu versetzen, bevor das nächste Szenario die Ausführung beginnt. Die einzige Möglichkeit, dieses Problem zu Kiwi's beforeEach besteht darin, Kiwi's beforeEach Hook mit einer Methode zu schreiben, die einen Soft-Reset einer Anwendung wie Kiwi's beforeEach ausführt:

+ (void)resetApplication {
[Session invalidateSession];
[LocationManager resetInstance];

[((NavigationController *)[UIApplication sharedApplication].delegate.window.rootViewController) popToRootViewControllerAnimated:NO];

[OHHTTPStubs removeAllStubs];

cleanDatabase();

shouldEventuallyBeTrue(^BOOL{
    return FirstScreen.isCurrentScreen;
});

aber im Falle einer Anwendung, die Netzwerk-, asynchrone Jobs, Kerndaten, Dateioperationen involviert, wird es schwierig, einen wirklichen Abbau von Dingen durchzuführen, die von vorherigem Szenario übrig geblieben sind.

Frage

Das oben beschriebene Problem brachte mich dazu, darüber nachzudenken, ob es möglich ist, einen komplexeren Ansatz zu implementieren, ähnlich wie Franks Ansatz, mit einer zweiten App, die sich vom Paket der Hauptanwendung entfernt und nicht auf externe Tools wie Cucumber (Ruby) angewiesen ist.

Hier sehe ich, wie es gemacht werden kann.

Neben einer Hauptanwendung (MainApp) gibt es eine zweite iOS (oder Mac OS X) -App (AcceptanceTestsRunnerApp), die die gesamte Akzeptanztestsuite enthält und diese Suite mit einem Haupt-App-Bundle ausführt:

Es startet eine neue Simulatorinstanz, bevor es in jedes neue Szenario eintritt, und führt das aktuelle Szenario gegen die Instanz des aktuellen Simulators aus.

Die Frage ist:

Ich bin nicht gut genug informiert über Mac OSX oder iOS-Technologien, die mir erlauben würden, das zu tun: Ich weiß nicht, ob es überhaupt möglich ist, eine Mac OS X / iOS-Anwendung (AcceptanceTestsRunnerApp) einzurichten, die die Kontrolle über eine Haupt-App übernehmen könnte (MainApp) und führen Sie Akzeptanztest-Szenarien dagegen durch.

Ich werde dankbar sein für irgendwelche Gedanken / Vorschläge, die Leute haben, die sich wohler fühlen, ob sie ein natives Objective-C-Tool zum Schreiben von Akzeptanztests für iOS-Anwendungen haben.

AKTUALISIERT SPÄTER

... Ich habe einige Dokumente über XPC-Dienste gelesen, aber die Ironie dabei ist, dass das Schema, nach dem ich suche, ganz im Gegensatz zu dem Schema stehen sollte, das die XPC-Dokumentation vorschlägt:

Idealerweise möchte ich, dass meine AcceptanceTestsRunnerApp über MainApp dominiert: Sie führt sie aus und steuert sie (Benutzerinteraktionen, Behauptungen über die Ansichtshierarchie) über ein Objektproxying zu MainApps Anwendungsdelegaten, während XPC-Services-Setup annehmen würde, dass der XPC-Dienst (AcceptanceTestsRunnerApp) einer App untergeordnet ist (MainApp) ) und der XPC-Dienst benötigt, um im App-Bundle zu leben, was ich auf jeden Fall vermeiden möchte.

... Meine aktuelle Lesung ist verteilte Objekte Programmierungsthemen . Es scheint mir, dass ich meine Antwort dort finden werde. Wenn mir niemand Anleitungen oder Anweisungen gibt, werde ich eine Antwort über meine eigenen Forschungen und Gedanken schreiben.

... Dies ist der nächste Schritt in meiner Suche: Verteilte Objekte auf iOS .