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.
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”.
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.
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.
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.
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?
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]
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]
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.
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.
When a test fails, we want to know the location of the failure. Getting this information in Objective-C required us to dance with the preprocessor. But with Swift, it’s much more straightforward.