Quality Coding

Category Archives for iOS Unit Testing

Emoji: Woman Artist

3 Easy Steps for Designing iOS Unit Tests


(While I’m busy finishing my book, here’s a guest post from Ellie Coverdale. Take it away, Ellie… —Jon)

Unit testing is an important part of establishing the correct functionality of the individual units of a single software program. Software can get deeply complex, with all sorts of potential elements making life more difficult for you as you try to get a picture of the program as a whole. The more complex the software, the more complex the units and, often, the more of them there are to have to contend with as you go through your development process.

By isolating components of your software you can put together a checklist that lets you establish what works and what doesn’t in your application. In essence, a unit test is not a particularly complex concept. In fact, it’s all about clarity and simplicity. However, architecting a unit test has a certain complexity to it that needs to be cut through for you to succeed in your goal. So, with all of that said, let’s look at three simple steps to constructing iOS unit tests with clarity and efficiency.

Continue reading

Emoji: Bust in Silhouette

How to Mock Standalone Functions in Swift


We’ve looked at ways to mock methods in Swift. But what about standalone functions? Is there a way to mock them as well?

Yes! Not only can we mock Swift standalone functions, but we can do it without changing the call sites.

Continue reading

Emoji: Bamboo

Swift Mock Objects: How to Avoid Fragile Tests


I’ve written about my experience of going to try! Swift Tokyo 2017. Now thanks to the video and transcript provided by Realm, I can also share the talk I gave: “Making Mock Objects More Useful”.

Speaking at try! Swift Tokyo on Swift Mock Objects

I start by showing the basics of how to make a Swift mock object by hand. But this easily leads to fragile tests because the assertions are overspecified. We need ways to make tests more malleable, with mocks that are more flexible.

Continue reading

Emoji: Man Shrugging

Let’s Stop Overusing Swift Equatables in Unit Tests


Enumerations with associated values are my favorite feature of Swift. But how can we write unit tests against them? “Make them Equatable and use XCTAssertEqual” is common advice.

I’m here to argue otherwise. In fact, let’s use this as a jumping-off point to discuss Swift Equatables in unit tests.

Continue reading

Emoji: Drama Masks

Partial Mock: Have You Wished You Could Fake a Return Value in Swift?


I’ve shown you how to replace real objects with fakes in Swift, so that you can begin creating useful Swift mock objects. We did this by moving away from a concrete type to a protocol. Anything that implements the protocol will work, so fakes are no problem.

But what do we do when we can’t change the signature? How do we substitute fake arguments, or a fake return value?

It’s time to talk about partial mocks in Swift.

Continue reading

Emoji: Two Busts in Silhouette

6 Tips for Designing Effective Swift Mock Objects


Last time, we looked at How Does Swift Support Stubbing and Mocking? Swift’s extension declaration opens the way, letting us attach new protocols to existing classes. That much is well-known in the Swift community.

But then what? How do we create useful Swift mock objects? I’ve seen many examples that are okay… to start with. But in the long run, I’m afraid they’ll fall short for ongoing maintenance.

I wrote OCMockito because I wanted Objective-C mock objects that struck a better balance between “precise” and “forgiving”. I also wanted test code that was easier to read and write. What can we do with Swift mocking?

Continue reading

Emoji: Thinking Face

How to Use Protocols for Swift Mocking and Stubbing


You’re writing a unit test in Swift. You feel the need to avoid interactions with a real object. You want to provide a fake object, a mock, or a “test double” (like a stunt double). But Swift is strict about types! How can we do Swift mocking?

[This post is part of the series TDD Sample App: The Complete Collection …So Far]

Continue reading

Emoji: Signal Strength Symbol

How to Structure Tests that Do Real Networking


I try to avoid asynchronous tests because they’re slow. But sometimes they’re worth having. When you do have them, it’s worth spending extra effort to make them as fast as possible.

My mistake was that I only focused on the speed of the happy path. Today, I learned a way to improve the speed of failure scenarios, at least around testing network requests.

Test speed matters a great deal. In Test-Driven Development, you want to repeatedly take small, verified steps. Fast feedback is crucial to the process.

But even apart from TDD, test speed is important to keep your whole team moving forward. When someone submits a pull request, your build system builds your system and runs its tests. The time that requires stalls that particular pull request. And the more simultaneous pull requests you have, the worse things get.

Let me rephrase that in a positive way: small wins in test speed can accumulate into big wins for your entire team.

So let’s look at an asynchronous test that does real networking. If you have any tests like this, there may be an opportunity to improve their speed.

[This post is part of the series TDD Sample App: The Complete Collection …So Far]

Continue reading

Emoji: Disappointed

Most Swift Folks Are Wrong about XCTestCase tearDown…


Since 2001, I’ve relied on an understanding of test execution flow in xUnit frameworks. But somewhere along the way, my understanding of the XCTestCase life cycle got messed up. I picked up an assumption that’s just wrong.

At best, it’s an assumption that can bloat our test runs. At worst, it can wreak havoc.

Continue reading

Emoji: Woman Scientist

Why Unit Test View Controllers? For the Powerful Benefit


I’ve been unit testing view controllers since I started iOS back in 2010. My old Objective-C screencast How to Do UIViewController TDD is for folks who want to do TDD, but couldn’t figure out how in a programming model centered around view controllers.

But for every person who wants to know how, there are others who question the whole idea. They wonder if unit testing view controllers is worth it at all. So this time let’s skip the “how” and focus on the “why”.

One reader asked me how to win over a team lead who is test-reluctant. The team lead wanted the reader to stop spending time writing unit tests for view controllers. “He questioned why I unit test UI when it seems to take a long time and does not seem necessary.”

I can relate to that. At one job, I had to fight for permission to write unit tests of view controllers! The permission granted was only partial at first: I was allowed to write such tests as long as they were kept in a target that wasn’t run on the build server. This was a major pain for me! It meant that any time a developer made a change that broke my tests, neither they nor I knew about it. (After a couple of months, I finally moved these tests to the regular test target.)

So the question of whether one should write unit tests against view controllers is either a question you yourself ask, or one you will be asked. I have good reasons for what I do. But the real benefit is in the reason behind the reasons. Read on, and I’ll show you what I mean.

Continue reading

1 2 3