Archives For Architecture & Design

Design sense is very important for TDD. This category contains every article I’ve written on iOS Architecture and Design, for both Objective-C and Swift.

Code that’s easier to understand, maintain, and extend — that’s the promise of Object-Oriented Programming. But the reality for many iOS developers is that our objects are bloated. They know too much, and do too much. What if our code has hidden objects, waiting to be found?

Each hidden object could provide a new abstraction, a new tool. They could make the code more manageable. Is there a way to discover these hidden objects? Domain Driven Design (DDD) provides a way.

Continue Reading…

How can we unit test JSON parsing, handling every possible error? Can we generate immutable models? And for Swift, how can we keep our Response Models free of optionals?

Of course, there areb many JSON parsing libraries out there. Plug one in, define all fields as non-optional, and you’re good to go! …Until your app crashes, because something was different in the actual JSON data.

Unlikely? “The backend team would never do that to us”? I’ve had a released app crash because the backend folks changed one field from a string to an integer. I’ve seen app development and QA forced to pause because a commit assumed all fields were non-optional. (It crashed on the missing field, because Swift.)

So let’s look at a pattern that will help us

  • Handle required types
  • Avoid optionals
  • Deliver immutable models

Even if you never plan to do your own parsing, we’ll learn things along the way about design and testing. Continue Reading…

When you’re new to Test-Driven Development, there’s a strong tendency to continue writing code the way you used to. Then you step back and ask, “But how can you unit test this? TDD is so impractical!”

Almost always, my answer is: “Then don’t write it like that.”

Apple recently published a blog post, Working with JSON in Swift. I was looking for tips on Swift JSON parsing, and found the beginning of the article quite helpful. But it took a bad turn at the end… Continue Reading…

You face a problem with your code. Maybe something is bugging you about the design approach. Or maybe you’re just plain stuck. What can you do to break through a mental block?

"Free Your Mind" graffiti

free your mind by justanotherhuman, used under CC BY-NC 2.0 / Cropped from original

During one job interview, I remember asking how the candidate approached problem solving. That candidate’s answer has stuck with me over the years: Continue Reading…

I’ve been TDDing the “fetch characters” network request to the Marvel Comics API. But I’m anxious to see it work in a full round-trip to the actual Marvel server. Basically, I don’t want to go long without end-to-end feedback. How can I get the feedback I need to validate the current code?

Answer: Quickly hack together any way that works.

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!

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:

When you’re hiking and don’t know which way to go, what should you do? Stop. Get your bearings.

The same applies to Test Driven Development; sometimes you need to stop doing TDD, and get some answers.

Stop. Get your bearings. Spike Solution Techniques by Jon Reid

Those answers can come by switching from clean code to a style of quick-and-dirty hacking called a “spike solution.” I explained the basic idea in How to TDD the Unknown with a Spike Solution.

But what does it look like in practice? Continue Reading…

So you want to try Test Driven Development — great! But that requires expressing the intent of the code-to-be in automated tests. Where should you start if you don’t even know what the code should do? What should you do if you’re not confident about a particular approach?

You drive a spike through it!

To start my “Marvel Browser” iOS TDD sample app, I want to begin by making a network call to the Marvel API. If I knew what I was doing, I would start the 3-step “TDD waltz” of writing a single failing test, then writing the simplest code that passes, then refactoring.

But there are two roadblocks keeping me from writing my first test: Continue Reading…

objc.io is a monthly online magazine, with an editorial team. Each issue focuses on a particular subject, and Issue #15 is about Testing. I’m honored to be a contributor with my article “Dependency Injection”.

objc.io #15

Books

My article refers to two books I highly recommend:

  • Dependency Injection in .NET by Mark Seemann. This book is marvelous, and I need to study it more. (If you’re wondering why an Objective-C programmer is recommending a book with “.NET” in the title, you need to get out more. Learn what’s going on in other languages, and the smart folks who work in them.)
  • Working Effectively with Legacy Code by Michael Feathers. This now-classic text was instrumental to me when I first got started writing unit tests, helping me break through many conceptual barriers. Feathers boldly defines legacy code as “code without tests.”

Question: Do you have any comments about my Dependency Injection article, or any of the other Testing issue articles? Leave a comment below.