Unit Test Naming: The 3 Most Important Parts
You run your unit tests, and get a failure. How many times have you had to dig through the test code to try to understand what it’s complaining about?
Why does this matter? Because every time you have to read test code, you lose precious time. The feedback cycle lengthens, and you’re breaking your stride.
Instead, I try to code using fast feedback. When I run unit tests and get a failure, I want to understand what I broke. And I want to do this without reading the test code. The test name alone can give you the information you need.
In this post, I’ll describe the unit test naming pattern that can give you feedback from the name alone.
What’s in a name? — Romeo and Juliet, Act 2, Scene 2
How Remote Mob Programming Is Working for Me
Ever since I experienced mob programming, it became my primary teaching tool. But due to COVID-19, it’s suddenly time for me to support remote workshops. Can mob programming work remotely?
To date, I’ve taught over 230 students about unit testing and Test-Driven Development. Almost all has been in person, with everyone in one room.
My last TDD for iOS workshop was going to be in Amsterdam. But with the unfolding health crisis, my host Jeroen Leenarts and I decided to make the workshop fully remote. I’d been intending to start remote workshops some day, but this forced my hand.
In this post, I want to share how my remote mob programming is evolving. And you can add your own ideas.
Don't Lose Your “Flow”… Quickly Generate Test Code!
Subscribe to Download these FREE Code Snippets
Languages: Swift and Objective-C
IDEs: Xcode and AppCode
You’ll get our newsletter on Clean Code techniques for iOS developers. And you’ll get instant access to these code snippets!
We take your privacy seriously. See our privacy policy here.
3 Easy Steps for Designing iOS Unit Tests
(While I’m busy finishing my book, here’s a guest post from Ellie Coverdale. Take it away, Ellie… —Jon)
Unit testing is an important part of establishing the correct functionality of the individual units of a single software program. Software can get deeply complex, with all sorts of potential elements making life more difficult for you as you try to get a picture of the program as a whole. The more complex the software, the more complex the units and, often, the more of them there are to have to contend with as you go through your development process.
By isolating components of your software you can put together a checklist that lets you establish what works and what doesn’t in your application. In essence, a unit test is not a particularly complex concept. In fact, it’s all about clarity and simplicity. However, architecting a unit test has a certain complexity to it that needs to be cut through for you to succeed in your goal. So, with all of that said, let’s look at three simple steps to constructing iOS unit tests with clarity and efficiency.
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.
Kotlin! Got Any Interesting Language/Testing Tips for Me?
This week, I’m learning Kotlin. And what better way to learn a new language than by writing unit tests against the code?
What’s going on, you ask? Is the world coming to an end?
Advanced TDD Workshop for iOS Developers — On Sale Now
Have you done a few TDD exercises, but wonder how to bring it to your actual production code? Are you doing TDD in production code, but only for the simplest business rules? Did you TDD something only to feel it went poorly, and left your code worse off? Then it sounds like you’re ready for an Advanced TDD class.
How to Localize a Mobile App for International Markets
(While I’m busy writing my book, here’s a guest post on a topic close to me. I grew up in Japan as an American citizen, so I know how tricky it can be to cross cultures. Elisa Abbott gives us an overview of how localization is more than translating strings. —Jon)
As the world’s population is entering a phase of unprecedented growth, it’s essential to recognize that more and more people will own a smartphone. Billions of people don’t speak English as their native tongue, and maybe don’t know it at the most elementary level. This brings us to the idea that a high-quality localization (abbreviated l10n) of your app isn’t just an advantage — it will eventually become an indispensable part of app development.
Localization is the process of integrally translating your app content, yet also taking into account the linguistic peculiarities of a particular region. While this appears to be a very lengthy and strenuous process, research suggests that it has astonishing returns on investment. In this article, we’d like to look into the technicalities of localizing your app. Let’s dive right in, shall we?
Don’t Give Up on TDD Before Reaching Your Breakthrough
Dan Abramov recently tweeted:
TDD paralyzes me. I’m all for writing tests early in the process — especially in library code. But I can’t write them before I *play*. I need to write a shitty draft and play with the behavior to understand what I really want. Then rewrite guided by tests.
— Dan Abramov (@dan_abramov) January 19, 2019
That’s the beginning of a thread, so there’s more to it. But it gives me a chance to say to Dan, and the many folks who’ve shared this: You can still grow in Test-Driven Development. (Heck, I’m still growing.)
But instead of short tweets commenting on other short tweets, I thought I’d reply here. There’s room to discuss the gray areas.
Refactoring: How Do You Clean a Mess, Safely?
Refactoring is moving in small steps, with each step verified by unit tests. As I demonstrated last time, these steps are much smaller than most people are used to. Let’s continue the same example to learn some new things about refactoring.
Reading is not as good as doing. I learned from the folks at Big Nerd Ranch that our brains make important connections when we type code. Download my code and walk through the refactoring steps yourself.
When You Refactor, Are You Using Small Steps?
Refactoring remains a much-misunderstood discipline. Even when folks do have unit tests to back their changes, how long does the code stay broken? Let’s return to the idea that refactoring happens in very small steps.
No, even smaller than that.
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.
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.
Do You Refactor without Tests? It’s Time for Safety
When you refactor, do you have unit tests covering you? …If not, why not? …If so, how do you know?
To me, it seems that the state of refactoring has gotten worse across the industry. Both managers and programmers and managers say the word “refactoring” more than ever. But they almost always mean, “I’m going to change a bunch of stuff. Then at the end, we need to make sure I didn’t break anything.”
But that’s not refactoring. That’s rewriting.
How to Improve Code Comments with Little Refactorings
Does your code have comments? Sometimes they’re helpful. But most of the time…
Disclosure: The book links below are affiliate links. If you buy anything, I earn a commission, at no extra cost to you.
As Jeff Atwood explains, code tells you how, comments tell you why. A well-placed code comment is a level above the code itself, explaining why something is written the way it is. But! We can express most comments as code, using well-named identifiers. The first edition of the Refactoring book called this Introduce Explaining Variable. Martin Fowler has since renamed that refactoring to Extract Variable.