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]
Subscribe to Download these FREE Code Snippets
Languages: Swift and Objective-C
IDEs: Xcode and AppCode
You’ll get our newsletter on Clean Code techniques for iOS developers. And you’ll get instant access to these code snippets!
Let’s look at how a change to unit testing empowers TDD.
Robert Martin “Uncle Bob” creates strong impressions, with outlandish costumes and black-and-white statements. If you understand that this is his didactic style, you can appreciate him. 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 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?
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.
This is about speed. The more I trust the tests over a section of code, the more fearless I can be with bold refactoring. Fearless refactoring means I don’t spend time checking correctness. That’s what the tests are for! Instead, I can focus completely on good design.
So how can you increase confidence in your test code?