When I began my TDD Sample App, my hope was that it would help us explore a number of topics around TDD and Clean 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’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.