Reading up on iOS testing

4 Dec 2017

I'm about to start writing my first programming tests in Exist's iOS app. I've heard about tests before, and I like the idea of them, but I've never been able to really understand how to get started with testing.

My app is big enough now (and brittle enough, if I'm honest, because it's the first app I ever wrote, so it's carrying the baggage and cruft of my first four years learning to code), that it really needs test coverage. So I've been doing lots of reading about unit and UI testing, libraries and frameworks to use, best practices, and how to get started.

Here are some of my favourite resources from everything I've been reading, as well as a couple of observations about what I've learned.

Observations

The syntax is weird and nobody explains why

I've probably read 30 or 40 blog posts, articles, and tutorials over the past couple of weeks. And today is the first time I came across any explanation of why testing syntax is written in the way it is.

For instance, using Quick and Nimble, my tests look something like this (example taken from the Quick docs):

@import Quick;
@import Nimble;

QuickSpecBegin(DolphinSpec)

describe(@"a dolphin", ^{
  describe(@"its click", ^{
    it(@"has a high frequency", ^{
      Click *click = [[Dolphin new] click];
      expect(@(click.hasHighFrequency)).to(beTruthy());
    });
  });
});

QuickSpecEnd

In Quick's docs today I finally saw an example of how a test would log its result in Xcode, and realised why they're written like they are. They're designed to create a readable sentence when logged to the console. Here's an example from the Quick docs: DolphinSpec.a_dolphin_its_click_has_a_high_frequency

It's still a bit awkward to read, but it's designed to be close to a readable sentence, anyway.

Snapshot testing seems to require dummy data

Nobody's explained this in everything I've read, but since snapshot testing works by creating a diff between a reference screenshot and a screenshot taken during your test, I guess you need to use matching dummy data every time for dynamic layouts.

In Exist, for instance, the layout shows the user their data, which will change throughout the day and from day to day.

This is probably obvious to other people, but I found it confusing at first and wish one of the many people talking about snapshot testing would explain this explicitly.

Favourite resources

Quick Readme

Quick is the framework I'm using for my unit tests. The Readme is packed with mini-tutorials and info about best practices for writing tests as well as straight-up how-tos. I got some great ideas from this resource about naming and defining my tests.

Testing View Controllers with Quick

This is a short talk with transcript, but it had some good examples of how tests can seem like they're testing the UI, when they're actually testing code/logic.

Testing iOS Apps

This blog post offers neat explanations of handy concepts like red, green, refactor and arrange, act, assert. It also has some good ideas about general testing practices.

Snapshot Testing

I'd heard of snapshot testing, but I really had no idea how it works. This article gives a good overview of how it works and some of the tools you can use to do it.

UI testing iOS apps for humans

I've been confused about the best approach to UI testing for my app, so I was grateful to find this blog post that explores several options. It made me convinced I should give EarlGrey a try, and possibly use snapshots as well.