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.
Do you enjoy conferences and workshops? I’m looking forward to attending, teaching, and speaking at these events in the fall of 2016…
I learned how to write testable code in C++ and Objective-C. But what about Swift?
The features and the overall “feel” of a language can have a big impact on how we express our code. Many of you know this well, because you started Swift early, and are miles ahead of me. I’m delighted to play catch-up. Swift’s features are like new toys! …But how do they affect testability?[This post is part of the series TDD Sample App: The Complete Collection …So Far]
When I began my TDD Sample App, my hope was that it would help us explore a number of topics around TDD and Tidy Code.
On one hand, the app itself has barely progressed. However, the blog posts cover a surprising variety of topics.
You face a problem with your code. Maybe something is bugging you about the design approach. Or maybe you’re just plain stuck. What can you do to break through a mental block?
During one job interview, I remember asking how the candidate approached problem solving. That candidate’s answer has stuck with me over the years:
I stop the car. I get out of the car and walk around it. I get back in the car.
This really is “one weird trick,” and surprisingly effective. It acknowledges that repeating the same thing without change will probably yield the same result. So, stop.
Reminder: ‘Going for a walk’ is a pro debugging technique.
— Kris Jenkins (@krisajenkins) November 16, 2017
You see, once I’ve decided on a tentative approach, my mind digs in. It really wants to push through until that approach yields a solution. But if the approach doesn’t work, my mind keeps digging deeper — digging and digging until ruts form.
I need ways to dislodge my thinking out of that rut. I need to get access to different points of view. There’s one meta-trick, but here are 5 different ways to apply it:
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.
By “location of the failure,” I mean the file name and line number of the code that calls the assertion.
Swift, here I come!
It’s time to start another version of the MarvelBrowser project. As I did with the Objective-C version, I begin the Swift version with a spike solution. But the first time was to see if I could satisfy Marvel’s authentication requirements. Basically, I needed to get the incantation correct. This time, I know the steps to take, but I will repeat them in Swift.
I have two goals:
Could you give me feedback on the Swiftiness of my code?[This post is part of the series TDD Sample App: The Complete Collection …So Far]