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, 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?
You’re building a new network call to a server. The thing that will actually use this call isn’t ready. But you’re anxious to see the call work in a full round-trip to the actual server. Basically, you want to know: does this part of the code work? How can you get the feedback you need?
Answer: Quickly hack together any way that works.
The agile workflow is to build, validate, and adjust course. Extreme Programming teaches us to use many feedback loops. And fast feedback is the primary benefit of TDD. …But TDD isn’t the only way I’ve gotten feedback on my Marvel Browser:
This time, I want to combine these two approaches. It’s a hybrid for which I don’t have a name. Maybe a “spike test”?[This post is part of the series TDD Sample App: The Complete Collection …So Far]
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?[This post is part of the series TDD Sample App: The Complete Collection …So Far]
Let’s look at how a change to unit testing empowers TDD.
Robert Martin creates strong impressions, with outlandish costumes and black-and-white statements. If you understand that this is his didactic style, you might appreciate his content. (Sadly, his black-and-white statements also extend to hurting people, especially women and minorities.) But people seem to enjoy jumping on statements rather than trying to grasp the whole.
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 a blog post, Type Wars. Various people jumped all over this, with much LOL.
Who’s right? Is Martin 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 Martin’s statement, from my point of view. Finally, what do I think this means for Swift?
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? Share your tips in the comments below!
OCHamcrest matchers are predicates on steroids:
But OCHamcrest isn’t just a library of powerful matchers. It’s a framework for creating your own.
By creating a custom matcher, you create a small Domain-Specific Language. This will make your unit tests easier to write, easier to read, and self-diagnosing!
In this post, we’ll walk through the 9 steps of creating a custom OCHamcrest matcher.[This post is part of the series TDD Sample App: The Complete Collection …So Far]
AppCode vs. Xcode: Which is easier to use for unit testing? Which gives better feedback?
I’ve written about the big improvements to OCMockito’s error reporting. But when I ran the tests, I saw striking differences between the two IDEs.
Back in Xcode 4 days, Apple’s file template for Objective-C unit tests was awkward and bloated. So I made my own.
Fast-forward several years. I’m coding in Swift now. The first thing I want is unit tests — let’s create a new test suite.
Why am I not surprised that Apple’s template for Swift unit tests is filled with cruft?
Fine. I made my own.