Uncle Bob set off another firestorm with his blog post The Dark Path. Condemnation from the Swift programming community was, well, swift. How dare he insult our wonderful new language? Clearly he’s a n00b who hasn’t done enough Swift programming.
Except that he’s no n00b — not even close. As Mark Seemann said,
Perhaps you disagree with @unclebobmartin (at times I do), but remember: he's been programming all of YOUR LIFE. Don't presume him ignorant.
— Mark Seemann (@ploeh) January 14, 2017
I’m here to defend Uncle Bob’s post, as it relates to unit testing and TDD.
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]
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.
“Uncle Bob” Martin creates strong impressions, with outlandish costumes and black-and-white statements. If you understand that this is his didactic style, you can appreciate him fully. But people seem to enjoy jumping on statements rather than trying to grasp the whole. (Ah, Internet culture.)
I’m referring to the sentence: “You don’t need static type checking if you have 100% unit test coverage.”
This is one of the closing statements from Uncle Bob’s recent blog post, Type Wars. Various people jumped all over this, with much LOL.
Who’s right? Is Uncle Bob right? Are his detractors right?
Applying my faith to life, I find that “right and wrong” isn’t a helpful filter.
I want to start by trying to see the points of view of the detractors. But then I want to expand on Uncle Bob’s statement, from my point of view. Finally, what do I think this means for Swift?
The biggest benefit of Test-Driven Development is fast feedback. And so one of the best ways to keep your TDD effective is to make sure you get that feedback as fast as you can.
But most folks use their regular iOS app delegate when testing. This is a problem.
That’s because when you run your tests, it first fires up your app — which probably does a lot. A bunch of slow stuff. And that’s a bunch of slow stuff we don’t need or want for our tests.
How can we avoid this?[This post is part of the series TDD Sample App: The Complete Collection …So Far]
So you’ve tried to increase iOS unit testing in your organization.
Maybe you tried to lead by example, hoping others on your team would follow suit. Or maybe you tried to increase your own testing.
Either way, your efforts fell flat. Your new emphasis on testing was barely noticed, and eventually forgotten. Leading by example is key to introducing a test-driven culture to your organization. But it’s no good if no one sees your example.
If only there were a way to bring your tests in from the shadows, placing them front & center.
There is. It’s no silver bullet, but it’ll help. And it’s easier than you may think.[This post is part of the series TDD Sample App: The Complete Collection …So Far]
Dot notation is okay, after all.
There, I said it.
I’ve been a staunch opponent of dot notation. I saw it as obscuring messaging, and encouraging programmers to violate the Law of Demeter through chained dots. I went so far as to characterize dot notation as an Objective-C code smell.
So it may surprise you to learn that I’ve recently adopted dot notation in my code! Here’s how it happened…
There are subtle issues around #import order. You may not believe me — until you try reusing code in a new project.
In #imports gone wild! we looked at the problems caused by having too many #import directives. But it’s also possible that you have too few, resulting in bad header files — especially if you don’t pay attention to #import order in your .m files.
In my screencast of UIViewController TDD, I used an example of incrementing a counter and couldn’t help but give a slight aside: “We’ll increment it… ++count, instead of count++, please.”