I’ve been unit testing view controllers for as long as I’ve worked in iOS. My 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.”
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.Continue reading
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.
There’s been a growing debate about static languages vs. dynamic languages. For me, it started with Uncle Bob’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 concludes that there is a lack of evidence that static typing reduces defect density. The other more rigorous paper 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?
I’ve been TDDing the “fetch characters” network request to the Marvel Comics API. But I’m anxious to see it work in a full round-trip to the actual Marvel server. Basically, I don’t want to go long without end-to-end feedback. How can I get the feedback I need to validate the current code?
Answer: Quickly hack together any way that works.
My TDD has improved since I first started in 2001. But even today, I make mistakes. The trick is to learn to recognize TDD mistakes. Then, learn to “listen” to them: what is it trying to tell me about the design?
Follow along as I recount the latest steps in Marvel Browser, the iOS TDD sample app. Can you spot the errors before I point them out?
Let’s look at how a change to unit testing empowers TDD.
“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?
I’m always on the lookout for new tools. Are you? Anything that might increase programmer productivity is worth a look.
You know that I’m a big AppCode fan. It saves huge amounts of time. And doing so within an IDE helps me stay “in the zone.”
So I’d love to hear more from you. What are your favorite tools for productive programming? Click here to share your tips!