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?
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?
You spoke. The world is shifting. It’s time for Quality Coding to go Swift!
Better late than never.
“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?
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 iOS folks use their production 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?
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.
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.
When it comes to imports, header files should satisfy these two conditions:
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.”
I blame Apple for propagating poor incrementing style. Programming with Objective-C starts with the statement, “[Objective-C is] a superset of the C programming language.” But every example they give of incrementing a value uses
someInteger++, ignoring the fact that C has two different increment operators!
The Wikipedia article Increment and decrement operators gives clear examples of the difference.
What performance impact will it make? None. The extra code for post-increment semantics is probably optimized away by today’s compilers. Even if it’s not, it’ll still have almost no impact. So what does it matter?
It matters to the reader. It matters because it shows a lack of familiarity with the language’s operators, which doesn’t fill me with confidence in your code. It matters because Objective-C Is Still C (Not Java!)
Say what you mean, rather than relying on side-effects.
Question: Do language subtleties really matter? Leave a comment below.