Background
I’m looking for a way to implement a scheme similar to what Frank uses to implement Automated Acceptance Tests for Native iOS Applications, but I want this scheme to be based on native iOS / MacOSX technologies. Sorry for the next TLDR , but it deserves a detailed explanation.
1. Here is a brief overview of how Frank works:
It has client and server parts.
The server part is built into the application that we want to run acceptance tests. Frank's tutorials show us how to create a duplicate goal for the main goal of the application and include Frank with an HTTP server.
The client part is basically Cucumber , which runs scripts with plain text: each script contains directives that must be run against the application (fill in the text field, touch button, make sure there is a certain element on the page, etc.). Each script also launches its own instance of the application, thus providing a new state every time we introduce a new script.
The client (the bridge of the cucumber and Ruby-to-Objective-C) communicates with the server (HTTP server built into the application) through the HTTP protocol. It uses special conventions, so the client can tell the server what the application should do so that a specific scenario can be executed.
2. I recently found the following article, written by Frank Pete Hodgson, author:
http://blog.thepete.net/blog/2012/11/18/writing-ios-acceptance-tests-using-kiwi/
In it, he offers an easier way to write acceptance tests for developers who don’t like to rely on external tools like Cucumber and Ruby. Let me quote the author himself:
Before starting, let me make it clear that I personally will not use this approach to write acceptance tests. I prefer to use a higher level language such as ruby to write such tests. The test code is less efficient and more expressive, suggesting that you are comfortable in ruby. And that’s why I wanted to try this experiment. I have spoken to many iOS developers over time who are not able to write tests in ruby. They are more convenient in Objective-C than anything else, and would like to write their tests in the same language that they use for their production code. Fair enough.
This blog post inspired me to quickly collapse my very own very simple and primitive tool that accurately describes what Pete described on his blog: NativeAutomation .
Indeed, as described by Pete, you can run acceptance tests using only the Kiwi / PublicAutomation setting located in the simple OCTests target. I really liked it because:
- It is just pure C / Objective-C. It was very easy to create an initial group of C-helpers that look like Capybara helpers:
tapButtonWithTitle, fillTextFieldWithPlaceholder, hasLabelWithTitle, etc.
It does not require external tools and languages: there is no need for Cucumber / Ruby or anything else. NativeAutomation itself uses only the PublicAutomation , which Frank uses. PublicAutomation is necessary to simulate user interaction on the application screen: concerns, fills, gestures ...
It’s very convenient to run these tests directly from Xcode by simply running the Cocoa Unit Tests package. (Although builds on the command line are also easy).
Problem
The problem with Kiwi/PublicAutomation is that the entire test suite is built into the application package. This means that after running each script, the reset application cannot be made to be in a new state before the next script starts. The only way around this problem is to write Kiwi beforeEach hook using a method that performs soft-reset applications, for example:
+ (void)resetApplication { [Session invalidateSession]; [LocationManager resetInstance]; [((NavigationController *)[UIApplication sharedApplication].delegate.window.rootViewController) popToRootViewControllerAnimated:NO]; [OHHTTPStubs removeAllStubs]; cleanDatabase(); shouldEventuallyBeTrue(^BOOL{ return FirstScreen.isCurrentScreen; });
but in the case of an application that is associated with network, asynchronous jobs, master data, file operations, it becomes difficult to actually disable the material left by the previous script.
Question
The problem described above made me think about whether it is possible to implement a more complex approach, similar to the Frank method, with a second application that works separately from the main application package and does not rely on external tools such as Cucumber (Ruby).
This is how I see how this can be done.
In addition to the main application (MainApp), there is a second iOS application (or Mac OS X) (AcceptanceTestsRunnerApp), which contains the entire set of acceptance tests and runs this package against the main application package:
It launches a new instance of the simulator before it enters each new script, and runs the current script against the current instance of the simulator application.
The question arises:
I am not well aware of the Mac OSX or iOS technologies that would allow me to do this: I do not know if it is even possible to install the Mac OS X / iOS application (AcceptanceTestsRunnerApp), which may require control over the main application (MainApp) and running acceptance test scripts against him.
I will be grateful for any thoughts / suggestions that people who feel more comfortable with their own Objective-C tool for writing acceptance tests for iOS applications may have.
UPDATED LATER
... I read some documentation about XPC services, but the irony is that the circuit I'm looking for should be exactly the opposite of the circuit described in the XPC documentation:
Ideally, I want my AcceptanceTestsRunnerApp to dominate MainApp: run it and control it (user interactions, statements about the view hierarchy) through some object proxying the delegate of the MainApp application, while setting up XPC services assumes that the XPC service (AcceptanceTestsRunnerApp ) will obey the app (MainApp), and you will need an XPC service to live inside the application package, which I want to avoid in all ways.
... My current reading is Distributed Object Programming Topics . It seems to me that I will find my answer there. If no one provides me with guidance or guidance, I will send an answer about my own research and thoughts.
... This is the next step in my quest: Distributed objects in iOS .