Refactoring. It’s a word I hear quite a bit. Usually, in the context of conversations with management, it means, “Rewriting that thing. Hopefully without introducing bugs.” Often, among developers, it means, “One of the options in the Refactoring menu in my IDE.”
How can we use Test-Driven Development for JSON parsing? Most developers are concerned with ways to implement the production code. There are various approaches, various libraries… But what about the unit test side of things?
If we write effective unit tests, the design can appear incrementally. And with a strong suite of tests, you’re free to change the implementation — even radically. When the results are guaranteed by tests, whatever approach you take or library you use becomes an implementation detail!
Last time, we looked at design principles, such as sticking to the Single Responsibility Principle and returning a Response Model. This time, let’s look at:
Let’s look at how a change to unit testing empowers TDD.
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.
The definitive book on this topic is xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros. It’s a big book, full of patterns and smells. But there are 3 simple steps I take most often.
This is a five-minute screencast where I’m refactoring tests in my iOS TDD sample app using those 3 steps:
A Value Object is a handy way to combine multiple values in a single object. It sounds simple — you just make each value a property, right? Well, there’s usually more to it than that. There’s even an entire objc.io article about Value Objects. …So how do you define a new Value Object?
I believe in laziness. Let’s do as little work as possible!
AppCode is an alternative IDE for Objective-C development. When it comes to test driven development, it’s superior to Xcode. But that’s not all. Check out the “inside-out” coding style it makes possible.
In general, AppCode lets me focus more quickly on semantics and less on fiddling with source code.
Are you interested in the AppCode templates I use?
Question: What other AppCode tricks do you like? Leave a comment below.
Remember my iOS Model-View-Controller TDD screencast? Eric Baker took it a few extra steps with his own follow-up screencast, demonstrating:
There’s a lot of interesting stuff here. But I also want to acknowledge that this screencast changed my mind about dot notation. Yes, really!
What are your thoughts about ReactiveCocoa, Kiwi, or AppCode? Leave a comment below.
The UIViewController TDD screencast ended with all the code in the view controller. Unfortunately, this is where many iOS programmers leave things! Let’s TDD our way to something better…
In part 2, we pick up from there and TDD to extract a model class, which the controller observes. You’ll see it evolve into true Model-View-Controller, driven by unit tests.
In particular, you’ll see how to TDD:
This screencast focuses on the question I get the most: “Do you do test-driven development for view controllers?” It’s clearly a roadblock for many people. This screencast should remove that roadblock.
It also answers the question, “Is it worth doing?”