Optimize your testing workflow with Xcode keyboard shortcuts
Testing can feel like a drag when your editor is working against you. Constantly jumping between files and running lengthy test suites can drop you out of the flow of productive coding.
In this article, you’ll learn how you can use Xcode shortcuts and features to efficiently navigate the interface without leaving the comfort of your keyboard.
The assistant editor
The first key to efficiently testing your code is to use Xcode’s assistant editor. The assistant editor is a companion editor to your currently open file. It can be enabled using the Related Content button in the top right corner of your current editor
It can also be summoned using
CMD+CTRL+OPT+Return. This opens a separate pane to the right of your editor, displaying your code’s counterparts.
A counterpart is a file that Xcode thinks is related to the source file you’re editing. For example, Objective-C’s implementation and header files are counterparts. And lucky for us, if your test file is named correctly, it’ll show up in the list as well!
In order for your tests file to show as a counterpart, it needs to be called
The assistant editor can sometimes identify multiple counterpart files, meaning it may not show you the one you want by default.
If this happens, you can quickly cycle through them using
You can change the selected counterpart using the breadcrumb bar above your assistant editor.
Jumping between the main editor and assistant editor
You’ll often be jumping back and forth between your app code and tests, which can easily disrupt your state of flow. so it’s natural to use a keyboard shortcut for that.
To cycle through the different open editor panes, you can use
Running tests from the keyboard
When it comes to running tests, you have many options.
CMD+U to build your test target and run all tests. This is most useful when you want to ensure that all tests in your project are green. However, as your test suite grows, you may want to opt for more time efficient options.
Sometimes, you simply want to build your test suite to see if the compiler catches any errors, without running any tests. To do so, use
SHIFT+CMD+U. Think of this like
CMD+B, which builds your project without running it.
To run the currently highlighted test, you can use
CTRL-OPT-CMD-U. If you’re in the scope of your
XCTestCase but not any specific test, it will run all tests in the test case. This is most useful when you’re focused on a specific test or component.
And the coup de grace is
CTRL-OPT-CMD-G. This shortcut runs the most recent set of tests executed by Xcode. If you ran a single test, with will run it again. If you ran the whole suite, it’ll run the whole suite again.
What does this mean for your testing workflow?
Let’s tie all these shortcuts together.
You’ve just opened Xcode and you’re ready to work! Open a code file using the project navigator or Quick Open (
Then, open the assistant editor using
CTRL+OPT+CMD+Return. If your tests file isn’t shown by default, cycle through the different counterpart options using
CTRL+CMD+up/down. If you want to start writing a test, use
CTRL+` to hop over to the assistant editor.
As you’re navigating your tests file, move outside the scope of a test method and hit
CTRL+OPT+CMD+U to run all the tests in that file. This will give you a baseline from which to work, as well as setting up our next step.
Now you can quickly move back and forth between the test file and the code file using
CTRL+`. When you want to run the tests in your file, use
CMD+OPT+CMD+G in any code editor.
Finally, once you’re done with your specific component, you can run the whole test suite by hitting
CMD+U to ensure the rest of your tests are still passing.
Efficiently creating new files and tests
The final point of friction that we want to address is when we create new files.
In an ideal world, we would create both a Swift file for our application target, as well as a tests file for our tests target, while ensuring both are consistently named in order to be used with the assistant editor.
To accomplish this, a simple approach would be to use an Xcode File Template that would take could take our file name, create both files in their correct locations, and add them to their respective targets.
Unfortunately, this is not currently possible. The current File Template format only allows us to add files to a single target, which conflicts with what we want to create.
We’ve filed FB9725680 in hopes to get this addressed by the Xcode team. In the meantime, feel free to dupe it if you’d like to see this added as well.
Until then, we’re stuck creating both files separately.