Quality Coding
Shares

All posts by Jon Reid

Emoji: Writing Hand

My Crazy Plans for the New Year (Book Teaser)

Shares

Happy new year! It seems like good time for a Quality Coding retrospective. I also want to share some goals for 2018.

…Did someone say, “Are you writing a book?”

Continue reading

Emoji: Bust in Silhouette

How to Mock Standalone Functions in Swift

Shares

We’ve looked at ways to mock methods in Swift. But what about standalone functions? Is there a way to mock them as well?

Yes! Not only can we mock Swift standalone functions, but we can do it without changing the call sites.

Continue reading

Emoji: Female Detective

How to Use SwiftLint for Clean, Idiomatic Swift

Shares

We get feedback from the compiler. We get feedback from Test-Driven Development. But what sources of feedback lie in between?

This is where linters come in. A linter goes beyond “Does the code compile?” A linter answers questions like, “Is the code idiomatic? Is it stylistically clean? Are there any red flags?”

Continue reading

Emoji: No Good Gesture

What Can We Learn from an Incorrect TDD Diagram?

Shares

A paper published in 2013 about Test-Driven Development included the following diagram. Unfortunately, it gets some things wrong:

A tweet from Nat Pryce sparked discussion:

First, let me say I’m happy to see more studies on TDD. The thrust of this particular study is that TDD can be soft on negative tests. That is, maybe the code works for good data, but it’ll break on bad data.

TDD is a development discipline, so I’m all for learning more from traditional testing disciplines. I certainly don’t want to discourage folks from doing studies and writing papers.

But. Let’s first make sure we’re doing proper TDD, shall we? Otherwise any studies, especially studies about efficacy, may be flawed.

Continue reading

Emoji: Map Pin

Where Will Jon Be in Fall 2017?

Shares

Do you enjoy conferences and workshops? Here’s my conference schedule for this fall:

Continue reading

Emoji: Keycap Digit One

Does the Single Responsibility Principle Lead to Bad Architecture?

Shares

The “Single Responsibility Principle” (SRP) sounds so noble. But I’m afraid it’s misunderstood and misapplied. Ask your teammates: “What is the Single Responsibility Principle?” Go ahead, ask them. Then ask if the SRP is a good thing or a bad thing. I’d bet many of them will say something like this: “In principle, it’s a good idea. But in practice, it’s overkill.”

On Twitter, Chris Eidhof pointed to an example of taking the Single Responsibility Principle too far. Specifically, Chris was unhappy with the argument that Singletons violate the SRP because, besides their main responsibility, they also manage their own life cycle:

This led to a lively discussion. Many reacted against “over-architecture.” No doubt they experienced fragmented code that grew from over-zealous attempts at SRP.

I think that SRP isn’t just over-applied. It’s fundamentally misunderstood, even misquoted. The repeated misquotes perpetuate that misunderstanding.

Let’s see if we can clear things up, and point to a better way.

Continue reading

Emoji: Megaphone

Please Take My 2017 Reader Survey

Shares

I want to ensure my platform does the best possible job of answering your needs and interests. And that means I need to know more about you. To do that, I’ve created my 2017 Reader Survey.

Would you please take a few minutes to fill out the survey? By doing so, you will ultimately be helping yourself. Why? Because you will be helping me create content even more interesting and relevant to you.

Your input is important to me. The survey is easy to fill out, and the results are completely anonymous. I can’t tell who said what. And you can finish in five minutes.

Yes, I’m Happy to Help. Take Me to the Survey!

Thanks in advance for your help.

Refactoring Demo: Is It More than Just Changing Stuff?

Shares

Refactoring. It’s a word I hear quite a bit. Usually, in the context of conversations with management, it means, “Rewriting that thing. Hopefully without introducing bugs.” Often, among developers, it means, “One of the options in the Refactoring menu in my IDE.”

Inigo Montoya meme: "Refactoring, you keep using that word. I do not think it means what you think it means."

Continue reading

Emoji: See-No-Evil Monkey

Revealing Hidden Objects: Can Domain-Driven Design Improve Your Code?

Shares

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 provides a way.

Disclosure: The book links below are affiliate links. If you buy anything, I earn a commission, at no extra cost to you.

Eric Evans’ Domain-Driven Design is a book with many facets. One of my big takeaways is that our code often contains concepts that are hidden. The book’s challenge to me is to recognize implicit concepts, and make them explicit.


I stumbled upon this in the TDD sample app. While applying a principle from the book to the Fetch Characters Marvel Service, I uncovered a useful class.

Continue reading

Emoji: Bamboo

Swift Mock Objects: How to Avoid Fragile Tests

Shares

I’ve written about my experience of going to try! Swift Tokyo 2017. Now thanks to the video and transcript provided by Realm, I can also share the talk I gave: “Making Mock Objects More Useful”.

Speaking at try! Swift Tokyo on Swift Mock Objects

I start by showing the basics of how to make a Swift mock object by hand. But this easily leads to fragile tests because the assertions are overspecified. We need ways to make tests more malleable, with mocks that are more flexible.

Continue reading

>