Some Helpful Tips & Tricks for iOS Testing
In my years developing for iOS, I haven’t been willing to use tests on my apps. I didn’t believe it necessary and also felt that doing that would waste a lot of my development time. However, working with manual testing and bug fixing repeatedly allowed me to give this new way of working a chance.
The results were more than positive, but I have to admit that it wasn’t easy to start. As this is a new way of approaching development, we have to change the way we think before we code.
In this post I will tell you how I work on the creation of tests for the apps that we develop.
Tools
Xcode has its own framework to write tests, but I prefer to use a friendly library that promotes BBD. Its name is Quick and it is a behavior-driven development framework for Swift and Objective-C.
Another tool I use for test creation is OHHTTPStubs, a library designed to stub network requests very easily, very helpful.
What to Test?
Each function added to a model is a target for tests. In particular, I like to test the complete behaviour of an action from the user’s point of view. This is what BDD preaches and it is the process on which I rely for creating tests. With this principle I’m not going to test the specific function which activates a button, I’m going to test the final state of the app after the user presses the button.
It’s important to change the way in which we start to develop the functionality of an app. It’s always preferable to:
- Write the test
- Execute the test
- Wait for the test to fail (because the solution hasn’t been coded yet)
- Code the solution
- Write enough code fot the test to work
Like I said before, the main idea of BDD is to test the behaviour of an app. This means that we won’t match the results of a function or the properties of a model object. On the contrary, we will focus on visible and tangible elements for the users. We will test accordingly to the user’s actual response on the app, and what the final state after this response is.
A Spect Structure
BDD proposes a more narrative syntax for writing tests. The first group of tests is the Spec and by using Quick, the structure is as follows:
For the syntax of a test case, the more important blocks are it, describe and beforeEach. The it function is the one in charge of representing the acceptance criteria to validate the final state wanted.
The describe block allows us to specify a scene and group a serie of tests. For instance they can be grouped because they share the same initial setup. This setup can be written in another important block called: beforeEach, which is the code that will be executed before every it and describe block that is contained by the first describe. For more information about the Quick functions go to Organized Tests with Quick Examples and Example Groups.
The expect function is the one in charge of validate the expected result and will show us whether the test was successful or not. If you want to know more about the use of the expect function check out the Nimble’s github.
An Example
For this example the product owner requests a Login screen with the email and password inputs. It should confirm that the email is valid, otherwise it should show an error message in a label. It also has a button that navigates to the Sign up screen. It is a very basic example but interesting enough to start in world of tests and BDD.
In the beforeEach block (1) we write the code to initialize the navigation controller and the view controller we are going to test.
The first test is the one that should show an error message, as the describe indicates (2), we simulate the user pressing the login button without filling the email field. Then, in the it block (3) we use assertions to demonstrate how the app should behave. In this example we want that the label’s text be equal to “invalid email”.
Another simple example is the test which includes navigation to another screen after something happens. In this case, we want the app to go to the register screen after the user presses the sign up button (4). For this purpose, we simulate the button’s TuchUpInside event in the beforeEach function. In the it block we have to assert that the topViewController be equal to the class expected (SignUpViewController) using the class matcher beKindOf. However, the matcher equalTo is not valid in this case, because the last one makes the comparison immediately. As we know, the navigation takes some time. To solve this, I use the special Nimble’s matcher called toEventually, which makes expectations on values that are updated asynchronously, so when the topViewController class changes to the wanted one, it’ll be going to pass the test.
Run the tests (⌘ + U), it should fail every test. Now you should code the solution!
Summing Up!
The main idea of this post is that it is a kickoff for the use of tests in apps with a simple but real example. In future posts we are going to do tests on TableViewControllers and with HTTP requests using OHHTTPStubs.
