Over the passage of time working on different projects i’ve seen a lot of different automation frameworks to handle UI testing. Mostly quite similar, they rely on the concept of having deterministic mock data that will power your views, they then drive your views through a user journey to assert an expected outcome. Most of these frameworks follow the Behaviour Driven Development (BDD) approach to writing tests through their adoption of Cucumber, I won’t go into the details of these here as its not really relevant.
Xcode UI testing however takes a different stance and on my current project, we’ve used it more as a “no, don’t unit test that, its a view controller, write a UI test” style tool, rather than a fully fledged automation framework. What this really means is, we’re asserting things like “the menu only contains 5 items that match our mocked data” or “when you hit login an activity indicator view is displayed”; whereas in UI Automation land we’d be testing things like “given i’m a logged out user, then I enter text into username and text into password, then I hit login, I should be presented the welcome screen”… Or similar. So effectively we’re testing small discreet units of UI within our application.
The two things we soon discovered we’d need for this are:
The ability to inject dependencies where possible so we can load views without always necessarily progressing through a user journey to them.
The ability to test our views deterministically. This means we require MOCK data.
Why don’t we just go to the network, we can guarantee our API? Well, basically because you can’t. If you can run your test suite in a nuclear bunker, surrounded by a faraday cage with no outward or inward connectivity, then you’re onto a winner. The ability to be deterministic, to be certain that if your test fails its not because of some outward problem, but indeed due to a problem with your implementation, is vital for this specific type of testing. Other testing strategies such as end-to-end etc can accomodate this.
I’ve seen a few approaches to mocking data over the past decade. The common theme seems to be either one of:
Running a proxy that will returned canned responses to requests, configuring your network to use it as appropriate..
Littering all of your network code with #ifdef UI_AUTOMATION… and returning canned responses from an NSBundle.
In each individual test case, creating stubs and mocked responses for HTTP calls on the fly
All work, but it can be a little easier depending on your use case. SuperMock is inspired by both… a framework that you can drop into an existing code base, provide it with a simple .plist that maps network calls to canned responses in your NSBundle, functions as an NSURLConnection/NSURLSession proxy, but runs as part of your application test target, runs no server, requires no network and only leverages built in components of Foundation.
You have a menu in your application, which is dynamically driven from a web service, the contents of this menu can change at any time, but you’d like to assert that given some data, it populates and draws correctly on the screen.
Given the aforementioned problems… bring on the MOCK!
By defining your original/real URL in
of SuperMock and running 1 line (ok maybe 2) of code in your AppDelegate, you are able to guarantee the value of your menu items in your application. Making your UI Test case very simple to write and very reliable to run.
Now when your HTTP client fires off a request for
it will instead get returned
from the NSBundle you provided earlier. In your UI Tests (whatever framework you use), you can now assert based upon these MOCK values. Whats advantageous is that there is no more work to be done and no extra code in your test cases to stub out responses.
This is a short whirlwind tour of my latest little pet project, but expect to see feature like dynamic override of mocks (for use when you want the same URL to return different responses upon each request) and some more real world scenarios.
I’ll be using this framework a lot myself in my personal projects over the coming months, so I may tweak / change / improve / try not to break it, in the process. Right now its functional but not complete and needs a new README.md ?
https://github.com/michaelarmstrong/SuperMock / @ArmstrongAtWork