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…

If you’re interested in Swift development, and want to visit Japan, start making plans to go to the next try! Swift conference in Tokyo. It was my privilege to be a speaker earlier this month.

Let me share my impressions of the conference, and why you might consider making the trip there.

(But first, a side-note about this blog: Sorry I’ve been so quiet lately! I was spending my time preparing for try! Swift Tokyo 2017. Next up is CocoaConf Chicago, where I’ll be leading a TDD workshop in addition to giving a talk. But I’ve also continued to TDD a JSON parsing example, in both Objective-C and Swift versions, so I have plenty to blog about. To make sure you don’t miss any new articles, you can sign up to get updates via email.)

Logo

Riko

“Riko”, the official logo of try! Swift Tokyo

First, let me point out the conference’s logo/mascot. The Swift bird has never been so adorable! Without a doubt, this is the cutest tech conference logo I’ve ever seen. Continue Reading…

Enumerations with associated values are my favorite feature of Swift. But how can we write unit tests against them? “Make them Equatable and use XCTAssertEqual” is common advice.

I’m here to argue otherwise. In fact, let’s use this as a jumping-off point to discuss Swift Equatables in unit tests.

Apples and oranges: Sometimes you shouldn't care about Swift equatable testing Continue Reading…

Uncle Bob set off another firestorm with his blog post The Dark Path. Condemnation from the Swift programming community was, well, swift. How dare he insult our wonderful new language? Clearly he’s a n00b who hasn’t done enough Swift programming.

Emperor Palpatine: "Good, good, let the hate flow through you"

Except that he’s no n00b — not even close. As Mark Seemann said,

I’m here to defend Uncle Bob’s post, as it relates to unit testing and TDD. Continue Reading…

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:

  • Test principles
  • A TDD demo in Objective-C

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…

I’ve shown you how to replace real objects with fakes in Swift, so that you can begin creating useful mock objects. We did this by moving away from a concrete type to a protocol. Anything that implements the protocol will work, so fakes are no problem.

But what do we do when we can’t change the signature? How do we substitute fake arguments, or a fake return value?

It’s time to talk about partial mocks in Swift.

Continue Reading…

Last time, we looked at How Does Swift Support Stubbing and Mocking? Swift’s extension declaration opens the way, letting us attach new protocols to existing classes. That much is well-known in the Swift community.

But then what? How do we create useful mock objects? I’ve seen many examples that are okay… to start with. But in the long run, I’m afraid they’ll fall short for ongoing maintenance.

I wrote OCMockito because I wanted Objective-C mock objects that struck a better balance between “precise” and “forgiving”. I also wanted test code that was easier to read and write. What can we do with Swift mock objects? Continue Reading…

You’re writing a unit test in Swift. You feel the need to avoid interactions with a real object. You want to provide a fake object, or a “test double” (like a stunt double). But Swift is strict about types! What do we do?

Continue Reading…

I try to avoid asynchronous tests because they’re slow. But sometimes they’re worth having. When you do have them, it’s worth spending extra effort to make them as fast as possible.

My mistake was that I only focused on the speed of the happy path. Today, I learned a way to improve the speed of failure scenarios, at least around testing network requests.

Continue Reading…