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…
Subscribe to Download these FREE Code Snippets
Languages: Swift and Objective-C
IDEs: Xcode and AppCode
You’ll get our newsletter on Clean Code techniques for iOS developers. And you’ll get instant access to these code snippets!
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 for as long as I’ve worked in iOS. 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.
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]
You spoke. The world is shifting. It’s time for Quality Coding to go Swift!
Better late than never.
I want to thank everyone who participated in my 2016 reader survey. Your number one request was clear: “More Swift”.
When Apple first announced Swift, my Twitter feed was filled with folks struggling with the basic tooling. I need to get stuff done, so I waited while the early adopters took the hard knocks. You paved the way. Thank you.
There’s been a growing debate about static languages vs. dynamic languages. For me, it started with Robert Martin’s Type Wars, but it has expanded into many circles. Writing my own reaction helped me discover that I was unfairly judging Swift based on C++.
In the midst of the debate, another interesting article popped up: Eric Elliot’s The Shocking Secret About Static Types. It points to a couple of studies. One study concludes that there is a lack of evidence that static typing reduces defect density. The other study concludes, “There is a small but significant relationship between language class and defects.”
Check out Eric’s fascinating conclusion:
We’ve come full circle: a discussion about static types has again brought us back to TDD. Why?