Jon Reid

Coder / Trainer / Coach / Author / Speaker

I train iOS developers in technical agile practices.
…Because you can only be as agile as your code lets you be.

Nearly 2 Decades of TDD


I have 18 years of experience doing Unit Testing and Test-Driven Development (TDD) in Apple environments.

Unit Testing View Controllers 


Many say that unit tests should be done on model objects only. But View Controllers lie at the center of iOS programming. Learning to unit test them will greatly expand your safety net.

Refactoring: The Secret Sauce


Refactoring isn’t just moving stuff around with your IDE. Refactoring is changing the design of your code in small, verified steps. The goal: to drive down the cost of change.

Alaska Airlines

“Jon Reid fills a huge void in the iOS community when it comes to unit-testing and quality.”

Egencia

“Anyone who cares about unit testing for iOS would benefit from Jon’s workshop.”

E-gineering

“The entire team came away energized and ready to apply all the learnings to our day-to-day work.”

Simple

“Jon made writing tests fun and enjoyable. We’ve significantly increased our test coverage.”

Photo courtesy of NSSpain

eBay Motors app
eBay Instant Sale app
eBay Fashion app
Qik app
Skype app
Amex app

I’ve worked on a few iOS apps. I mention this here, to clarify that when I talk about unit testing iOS apps, I do so from actual experience.
Disclaimer: The content on this site is my own and doesn’t necessarily represent American Express’s positions, strategies, or opinions.

Book cover: iOS Unit Testing by Example

I’m the author of iOS Unit Testing By Example: XCTest Tips and Techniques using Swift.

My blogging frequency is low for now, while I concentrate on finishing my book. But here are a couple of my favorite posts. They both have short videos, and give you a feel for my style and content:

Emoji: Backhand Index Pointing Up

The 3 Laws of TDD: Focus on One Thing at a Time

When I was first learning TDD, I’d try to get to the First Step (a failing test) by writing a fully-formed test. But it often took a lot fiddling to get that test to run and fail. Sometimes this was because the production code took several steps to set up. Sometimes it was because the test code wasn’t right. One of the tricky parts of TDD is that we’re creating two streams of code in parallel: the test code, and the production code. Two things changing at the same time…

​Read More

My Story Starts with Being Fired

I worked at a Fortune 100 company. I was a member of a team responsible for maintaining a touchy framework. The code was brittle, and getting worse. Making successful changes became harder, and took longer. The team was afraid to touch the code, never knowing what else would break.

We tried to communicate these problems, but this made us look bad. Eventually, the company fired the entire team.

I Began Learning How to Create Safety

But before I was fired, in the midst of chaotic code, I began carving out areas of safety. This led to a series of happy chances:

  • I learned more about Object-Oriented Design. (These days, I think folks call it “Modeling.”)
  • This got me studying the Design Patterns book by the “Gang of Four.”
  • I eagerly searched for more resources on Design Patterns. This led me to a website where programmers were actively discussing them. (This was a brand-new type of site where anyone could change any page — the very first wiki. I became excited about wikis, and created the first wiki sites within the company.)
  • As it happens, the first wiki attracted discussion about three topics… One was exploring communication patterns in a wiki. Another was exploring Design Patterns. And yet another was exploring this thing called Extreme Programming.

Stumbling Across Extreme Programming Changed Me

Extreme Programming (XP) was “agile” before that term became popular. It was a set of values, practices, and feedback loops. extremeprogramming.org became my guide to a way of developing software that looked safe and sane. …It’s kind of nutty, since I wasn’t on a team that practiced XP. But I took what I was learning and applied it as best I could, on my own.

  • I learned about unit testing.
  • I wrote a unit testing framework. Back then, there was no platform support for unit testing frameworks, so you just used whatever you could find or make. Making my own unit testing framework taught me a lot about how they work. This was my first foray into discovering how tooling could make test code easier to write and manage.
  • When I had a chance to work on a greenfield project, I took my first stab at doing it test-first. This was nowhere near the disciplines of Test-Driven Development I’ve since learned. But it was a start!
  • I attended SD, the software development conference hosted by Dr. Dobb’s. There, I listened to Martin Fowler introduce his new book Refactoring. The talk was riveting: how to safely change software by following predetermined recipes. I immediately bought a copy on the spot.
  • There was a problem with Refactoring: it presumed the existence of unit tests. This helped me with the greenfield project, but what could I do about legacy code? Along came another book: Working Effectively with Legacy Code by Michael Feathers. This book gave me techniques for making existing code testable.

Once I learned how to add unit tests to legacy code, everything opened up.

Refactoring (1st edition cover)

Better Languages, Frameworks, and Platforms

So far, all of this was in C++. I’d carried a long wish to work with Smalltalk. Barring that, my next long wish was to work on NextStep, with Objective-C (which is the language part of Smalltalk, expressed in C). And wouldn’t you know it… Steve Jobs was back at Apple, and he brought NeXT with him.

Studying about mock objects led me to jMock. The matcher library Hamcrest was extracted out of jMock. So I wrote OCHamcrest, an Objective-C port of Hamcrest.

I had one gig working on Mac & Windows. Mac was Cocoa, Windows was .NET. Looking into the unit testing frameworks for .NET, I chose NUnit. (A decade later, I still think of NUnit features that the Apple team has yet to deliver in XCTest.)

Then iOS happened. At the time, there were two competing unit testing frameworks: SenTestingKit and GHUnit, each with their advantages. (Apple eventually adopted SenTestingKit, rebranding it as OCUnit.)

Then I tried different approaches to mock objects. OCMock existed by then, patterned after jMock. But a friend pointed me to an alternative called Mockito. It offered tests that were both more readable and less fragile. So I wrote OCMockito, an Objective-C port of Mockito that used the matchers of OCHamcrest. (Here’s a page collecting the various tools I’ve made.)

Lately, I’ve been working in Swift, of course. I'm back at another Fortune 100 company. Everything about coding feels so different from that time the other company fired our team.

Hamcrest
Mockito logo

Blogging, Speaking, Teaching, Coaching

I started the Quality Coding blog. I started giving talks at my workplace. Eventually, I was tapped to teach Test-Driven Development to all new engineering hires at the main eBay campus.

And then, Mobile Central Europe — a new conference in Warsaw — asked me to come and speak. They took a gamble, since I hadn’t done any speaking outside my workplace. I discovered that I loved it. Apparently, in spite all my “ahs” and “ums”, I was pretty good at it, too: the conference voted me as “Best Speaker”.

Since then, I’ve spoken at the following conferences and meetups. (I’ve collected a page with all my recorded conference talks.)

  • AltConf 2019
  • Swift by Northwest 2018
  • Next Door Conf 2018
  • Silicon Valley Engineering Leadership Community (2018)
  • Swift by Northwest 2017
  • Silicon Valley Code Camp 2017
  • CocoaConf Chicago 2017
  • try! Swift Tokyo 2017
  • CocoaConf San Jose 2016
  • #Pragma Conference 2016
  • MCE^3 (2016)
  • CocoaPods Test Jam (2014)
  • CocoaConf San Jose 2014
  • NSSpain 2014
  • iOSDevUK 2014
  • eBay Tech Talk Berlin (2014)
  • Mobile Central Europe (2014)
Jon Reid teaching about Model View Presenter

Photo courtesy of Natasha Murashev @NatashaTheRobot

I began teaching a workshop to get iOS developers started with Test-Driven Development. It started as a half-day. Then became a full day. Now it’s two days. The workshop is hands-on in a big way, with active involvement from everyone. I think it’s a blast.

Now I’m also offering coaching to individuals and teams. Because what matters is you, your code, and the challenges you face.

>