Back in Xcode 4 days, Apple’s file template for unit tests was awkward and bloated. So I made my own.

Fast-forward 5 years to Xcode 7.3. I’m starting to write Swift. The first thing I want is unit tests — let’s create a new test suite. I look in Xcode’s file template library. Where’s the Swift unit testing template?

Where is it? Apple didn’t provide one?

Fine. I made my own.

Swift unit testing template

Edit: ⌘N for New File does let you choose the language. But not when you drag it in from the Utilities panel! In any case, the resulting file is stuffed with cruft which wastes your time. My template fixes that. Continue Reading…

Refactor tests, I say. Extract those helper methods. …But sometimes it’s not that simple! You have be careful when extracting an assertion test helper. Especially when it becomes long or complex.

YO DAWG, I HEARD YOU LIKE UNIT TESTS, SO I PUT UNIT TESTS IN YOUR UNIT TESTS SO YOU CAN TEST TESTS WHILE YOU TEST
Continue Reading…

Tests are code, too.” So you may ask: who tests the tests? Who watches the watchmen? Is TDD flawed, because it’s turtles all the way down?

stacked turtles

turtles” by Dan Machold, used under CC BY-NC-SA 2.0

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? Continue Reading…

Fast feedback is the chief benefit of TDD. Even if you’re not practicing TDD, anything that reduces the need to step through code saves a lot of time. For example, if you name your tests well, a test failure can tell you a lot just from the test’s name.

But what if you’re using a mock object? When a test fails, what can it tell you?

A hand-coded mock can tell you as much as you can code. But writing boilerplate gets old, so the reporting tends to be shallow.

And most mock object frameworks generate mocks that simply report, “Such-and-such was not invoked.”

This was also true of OCMockito. Until recently. Here are the 3 new descriptions of verification failures: Continue Reading…

xUnit Test PatternsI’ve given you 3 Reasons Why It’s Important to Refactor Tests. But what’s actually involved in refactoring tests?

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.

Here’s a five-minute screencast where I’m refactoring tests in my iOS TDD sample app using those 3 steps: Continue Reading…

You may have seen the 3 steps of “the TDD waltz”: Fail, Pass, Refactor. There are many ways to do it wrong! Two common mistakes are:

  • Skipping the refactoring step
  • Not skipping it, but refactoring only production code

So let me give you 3 reasons why it’s important to refactor tests.

Continue Reading…

Can you TDD networking requests? Sure! It’s just a matter of using Dependency Injection (DI).

But first, a quick recap. Remember this design?

Web request: Clean Architecture

We want a Service class. Now when I began using this style, I made a mistake: I created a single Service class to house an entire API. This violates the Single Responsibility Principle.

The Marvel Browser may end up supporting only one API call. But I’m afraid naming it MarvelService would lead people down the wrong road. We are fetching comic book characters. So let’s use a narrower name: FetchCharactersMarvelService.

Remember: Smaller, focused classes are easier to manage than larger, godlike ones.

Let’s TDD it! Continue Reading…

Before I start the first networking calls in the iOS 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…