Quality Coding

Category Archives for iOS Tools

Learning Kotlin Showed Me the Truth About Xcode


In my first-ever live stream, I used a TDD exercise to learn the basics of Kotlin. In this recording, you can watch as I let the IDE guide me, stumble through mistakes, and get help from viewers. You’ll get to see how much better a good IDE can be than what we experience with Xcode.

Aside from learning Kotlin itself, I experienced two big things. First, it showed me that with good tooling, Test-Driven Development is a nice way to learn a new language.

Second, I got to experience what it was like to do live coding on Twitch. This came about from talking with Ted Young, who broadcasts his test-driven coding nearly every day. Ted told why he does it and what he gets out of it. This gave me the courage to jump in and give it a whirl. With only a 5-minute warning that I was going live, I didn’t expect anyone to be watching. So it surprised me to have a couple of viewers jump in who helped guide me into Kotlin coding.

I don’t expect folks to watch the full 2 hours of me stumbling along. But let me give you some tips of ways this recording could be helpful to you. …Even if you’re a die-hard Swift programmer who would rather “be dead in a ditch” than learn Kotlin.

Continue reading

Emoji: Dice

Why Is Random Order a Big Deal for Test Quality?


Have you ever seen a unit test pass in isolation, but fail when run in a suite? Or vice versa, pass in a suite, but fail when run in isolation?

Besides the other improvements for test-centric workflows, Xcode 10 brought a rarity: a new XCTest feature for unit tests! Randomizing test order will help us flush out mistakes in the design of our tests.

Let’s start by examining a symptom… Have you ever seen naming like this in a test suite?

func test01RunThisTestFirst() { … }

func testCheckSomethingElse() { … }

This is a dirty trick to get the top test to run first, before any other tests in the suite. It relies on the fact that currently, tests within a suite run in lexicographic order. 01 comes early in ASCII, so test01RunThisTestFirst will run first.

Continue reading

Xcode beta

Joy! Xcode 10 Promises to Improve Test-Centric Workflows


Every WWDC, I hope for improvements to unit testing — but have learned to expect disappointment. So at WWDC 2018, I was surprised to have my low expectations thwarted! Xcode 10 brings changes that will improve my test-centric workflow.

For several years, Apple’s changes for test support have underwhelmed me. They focused on:

  • Xcode Bots (…I tried them. I gave up.)
  • Performance tests (…My code is not performance-critical.)
  • UI tests (…I don’t write any.)

With Test-Driven Development, unit tests run locally are my primary tool. The features above may have helped some people, but I wasn’t one of them.

So what did WWDC 2018 bring me? Here’s what I see on the horizon with Xcode 10.

Continue reading

Emoji: Female Detective

How to Use SwiftLint for Clean, Idiomatic Swift


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: Hatching Chick

Automatically Generate Swift tearDown with This AppCode Plugin


Those of you who are regular visitors to qualitycoding.org may have already read Jon’s article outlining the life cycle of XCTestCase objects during the execution of a test suite. If you haven’t, or you want to refresh your memory, take a moment to read the original article.

Jon discusses the importance of the setUp and tearDown methods. And, more specifically, why we should be deallocating our properties in the tearDown method.

Writing a tear down method is one of those repetitive tasks. It follows a specific pattern: all properties should be set to nil. It doesn’t really require any brain power. It’s just one of those annoying tasks that you have to remember to do when writing a test.

It’s tasks like this that should be automated. And now with the Swift tear down inspection AppCode plugin, we can.

Continue reading

Emoji: Wrench and Hammer

What Are Your Favorite Tools for Productive Programming?


I’m always on the lookout for new tools. Are you? Anything that might increase programmer productivity is worth a look.

You know that I’m a big AppCode fan. It saves huge amounts of time. And doing so within an IDE helps me stay “in the zone.”

I’ve shared about 6 Simple Power Tools for Better Git Use. Thanks to reader comments, I learned about Oh-My-Zsh for command-line, and SourceTree for GUI. AppCode also provides great Git support.

So I’d love to hear more from you. What are your favorite tools for productive programming? Share your tips in the comments below!

Emoji: Man and Woman Holding Hands

How to Make Your Own OCHamcrest Matcher for Powerful Asserts


OCHamcrest matchers are predicates on steroids:

  • You can combine them to create expressive assertions.
  • They describe mismatches in detail, reducing the need to debug.

But OCHamcrest isn’t just a library of powerful matchers. It’s a framework for creating your own.

By creating a custom matcher, you create a small Domain-Specific Language. This will make your unit tests easier to write, easier to read, and self-diagnosing!

In this post, we’ll walk through the 9 steps of creating a custom OCHamcrest matcher.

[This post is part of the series TDD Sample App: The Complete Collection …So Far]

Continue reading

AppCode vs. Xcode Unit Testing Battle


AppCode vs. Xcode: Which is easier to use for unit testing? Which gives better feedback?

I’ve written about the big improvements to OCMockito’s error reporting. But when I ran the tests, I saw striking differences between the two IDEs.

Continue reading

Swift custom XCTest file template

Would You Like an Improved Swift Unit Testing Template?


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

Fast-forward several years. I’m coding in Swift now. The first thing I want is unit tests — let’s create a new test suite.

Why am I not surprised that Apple’s template for Swift unit tests is filled with cruft?

Fine. I made my own.

Continue reading

Emoji: Bar Chart

Can OCMockito’s New Error Reporting Save You Time?


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

1 2 3