Did you know that Xcode behaviors can help change your behaviors as a developer?
Xcode lets us adjust its behavior on certain actions. I like to keep my development workflow centered on running tests. What’s a good setup for a test-centric workflow? Here are the settings I use to keep tests at the forefront of my coding.
[This post is part of the TDD with SwiftUI series.]
Xcode Behaviors in Settings
First, where do we see the Xcode behaviors, and what can we change? In the Xcode menu, select File > Settings or press ⌘, to open Settings. There are various tabs along the top of the settings window. Select the Behaviors tab.
The panel on the left side is a scrolling list of actions. It groups actions into categories like Build, Testing, and Running. We will focus on the Testing category.
“Testing Succeeds / Fails” Behaviors
The main behaviors I focus on are Testing Succeeds and Testing Fails. Here are the two settings I like for Testing Succeeds:
For both Succeeds and Fails, I enable:
- Play sound, and
- Notify using bezel or system notification.
Let’s discuss the bezel before we get to the sounds.
Bezel Showing Test Results
You may already have the second setting enabled since it comes that way by default. When testing completes, the bezel appears in the center of your screen, towards the bottom. Here’s what it looks like when testing succeeds:
Isn’t that nice? If you don’t see this on successful test runs, enable “Notify using bezel or system notification” and give it a try. Be sure to enable it for the Testing Fails behavior as well.
Sounds for Success or Failure
It’s not enough for me to see the results. I want to hear them as well. These are the sounds I like to use:
- Testing Succeeds: Pluck
- Testing Fails: Sonumi
(Yes, Apple changed the old name Sosumi slightly.)
Why do I like to play sounds for success and failure? Because they give me extra sensory input on top of my eyes seeing the bezels.
I run tests frequently, predicting whether they will succeed or fail. When I hear the matching sound, I get a little dopamine hit: “Good job! The test run came out just as you predicted!”
What if I hear a sound contrary to my prediction? That really grabs my attention. Did I predict success, but get failure? Did I predict a failure, but get success? Either way, when I get unexpected results, the gap between my prediction and reality reveals a gap in my mental model. Then it’s time to lean in and pay closer attention.
Running tests with these settings gamifies my coding. I run tests after making small changes, so the sight and sound give me sensory feedback. This in turn rewards me for running tests often. And that reminds me to make changes using small, verified steps.
Conclusion
My settings for Xcode behaviors live in a strange reinforcing loop:
- I established these Xcode behavior settings because I want testing at the center of my development workflow. But also,
- I start to crave the dopamine hit. Because I’m used to these settings, they remind me to keep running tests often.
In other words, these sights and sounds are not just outcomes. They are behavioral triggers.
After a while, this way of working becomes addictive. That’s why we used to say, “I’m test infected!”
How do you like to set up your Xcode behaviors, for testing and other categories? Share your tips in the comments below.
[This post is part of the TDD with SwiftUI series.]
