Before I start the first networking calls in the TDD sample app, I have a question for you.

How would you write unit tests for this code?

NSURLSession *session = [NSURLSession sharedSession];
NSURLSessionDataTask *dataTask = [session dataTaskWithURL:url
                                        completionHandler:completion];
[dataTask resume];

This fires off a request to download some data, then does something with that data. Most people would write the code pretty much this way. (Of course, supplying a URL and a completion block.)

Then they ask, “How do I unit test this?”

Think about it for a minute. What are your options?

Continue Reading…

If we’ve learned the Three Steps of TDD and the Three Laws of TDD, what keeps us from doing Test Driven Development? Maybe it’s not knowing how to write unit tests. Or more specifically, not knowing how to write unit tests against “real” code.

And what keeps us from writing unit tests against our own code? I bet it’s not knowing what our many options are.

Dependency Injection can unlock your code.

Unlock Your Code with Dependency Injection
Continue Reading…

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!

lazy bear

Lazy Day” by J J, used under CC BY-NC-ND 2.0

Continue Reading…

Objects are like horses. The less they know about their chaotic surroundings, the easier it is to control them.

We don’t want our objects to be spooked when there’s a lot going on. So let’s build ignorance into our systems.

But how? We typically write mobile apps with these things at the center:

We’re pair programming, with you driving. You’re using Xcode.

I don’t say anything because I don’t want to offend you. But you’re having to do So. Much. Typing.

1908 advertisement for Remington typewriter

They say typing isn’t the slowest part of programming. But as I sit with you, I wonder… Why isn’t the code automatically appearing? We’re on a computer working in a computer language, so why doesn’t the IDE understand your intent? Why do you have to make the same changes in so many places?

Oh yeah. You’re using Xcode. Continue Reading…

Many of you already use OCHamcrest, the matcher library I initially ported from Java back in 2008. I’m writing today to announce OCHamcrest 5.0.0, and to explain what you’ll get out of upgrading.

But first, what does it mean to jump from v4.3.2 to v5.0.0?

OCHamcrest
Continue Reading…

With the imminent release of iOS 9 and the usual fast adoption rate, many developers can finally start using APIs introduced in iOS 8. One of these is UIAlertController, which unifies code for alerts, action sheets, and iPad popovers.

UIAlertController presenting an iPad popover

So… can we write unit tests against a UIAlertController? Let’s learn some tricks for dealing with Cocoa Touch. Continue Reading…

iPhreaks is a terrific podcast done as a panel discussion. The panel often brings strong experience from other platforms. (In fact, iPhreaks is the iOS cousin to the Ruby Rogues panel.) They already discussed TDD in episode 95. Following up on that, I’m honored that they invited me as their guest to talk more about TDD and Testing in episode 116.

iphreaks Continue Reading…

We’ve TDD’d a class that should handle authentication to the Marvel API. It looks good in theory. But how do we know if it really works?

In addition to TDD-ing part of a system, it’s important to get feedback about the system as a whole. So before we go on to write code to request Marvel comic book characters by name, let’s make sure the authentication class works at all.

We’ll do that with an acceptance test.

Acceptance test: Snapping in a jigsaw piece Continue Reading…

If you don’t know what some code should do, you can’t TDD it. A spike solution (a throwaway experiment) gives enough information to begin the TDD process. But now we’re faced with design decisions: What methods do we want? How should they be organized? How should they be accessed?

With Test Driven Development, the surprising answer is: it doesn’t matter that much, because it’s going to change anyway.

Breaking “Analysis Paralysis” with TDD
Continue Reading…