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?

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…

How many times have you run your tests, gotten a failure, and had to go digging through the test code to try to understand what it’s complaining about? For many of you, you’re so used to doing this that you don’t even notice it’s a problem.

Every time you have to read test code, precious time is lost. The feedback cycle lengthens, and you’re breaking your stride.

Remember, we are trying to go for fast feedback. When I run unit tests and get a failure, I want to understand what I just broke. And I want to do this without reading the test code.

Ideally, the test name alone gives me the information I need. Continue Reading…

Hit ⌘U to run your tests. …Once the tests start executing, how long do you have to wait for the results?

If you waited more than a few seconds, you may have a problem. Because one surefire way to discourage Test Driven Development on your team is to have unit tests take 30 seconds or more.

When I was taking water safety training, one of the things we had to do was jump into the water fully clothed. You don’t normally notice the feel of your own clothing, so it’s surprising to feel how waterlogged clothes hinder every basic swimming movement. The training is to learn how to remove that clothing in the water, to restore normal swimming. It’s like shedding a heavy straitjacket; suddenly you can move again!

Many of us are tied down by our slow testing experiences. Slow tests mean it takes longer to get results. Taking longer to get results means we won’t run our tests as often. Not running our tests as often means we’re undercutting the core benefit of Test Driven Development — namely, getting feedback frequently.

So let’s restore normal movement by shedding those heavy tests and setting them aside. But which tests are “heavy”? And what do we do with them? Continue Reading…

The biggest benefit of Test Driven Development is fast feedback. And so one of the best ways to keep your TDD effective is to make sure you get that feedback as fast as you can.

But most iOS folks use their production app delegate when testing. This is a problem.

That’s because when you run your tests, it first fires up your app — which probably does a lot. A bunch of slow stuff. And that’s a bunch of slow stuff we don’t need or want for our tests.

How can we avoid this? Continue Reading…

Using a hammer to drive in a screw. I mean, it works, kind of.

But if you use a tool in a way other than its intended purpose, you’ll be missing its most important benefits.

It’s kind of like that with Test Driven Development.

Is TDD about preventing bugs? That’s more of a side effect than a direct goal.

Is it about making a test suite? Well, kind of. But… no. Not really. Continue Reading…

So you’ve tried to increase iOS unit testing in your organization.

Maybe you tried to lead by example, hoping others on your team would follow suit. Or maybe you tried to increase your own testing.

Either way, your efforts fell flat. Your new emphasis on testing was barely noticed, and eventually forgotten. Leading by example is key to introducing a test-driven culture to your organization. But it’s no good if no one sees your example.

If only there were a way to bring your tests in from the shadows, placing them front & center.

There is. It’s no silver bullet, but it’ll help. And it’s easier than you may think. Continue Reading…