Somehow, I’ve gone for years without being aware of this setting in the Test Targets used in Xcode projects. Apologies if this has been obvious to everyone on Earth other than me.
A Tangentially related background story, that enabled me to discover this setting
In my flash cards app, I needed logic to figure out which cards could be used for a given user’s ask/answer languages setting. For example, if a user wants to always use Korean as their ask language, and all other languages available as answer languages, then only cards that included Korean and at least one other language could be presented.
Also, bear in mind that for languages that have roman and non-roman script versions, they need to be treated as two separate languages, only one of which is relevant, depending on which the user has selected in Settings.
My first pass at the logic to pick the next card erred on the side of simple, rather than safe. It used the following process:
- Select the ask language (randomly if the user’s preference specifies multiple ask languages)
- Determine an answer languages list (again shuffle them randomly if there is more than 1 answer language)
- Find the list of words matching the ask language and the answer languages (a bug here was returning an empty word list when I specified a single answer language and there were no words yet with that language)
- Pick a word from the list
- Calculate the intersection of available languages for the word and answer language(s) specified by the user
- Return an object containing the wordId, the askLanguage and the array of answerLanguages
As I mention in the list, there is a bug in step 3 that can cause a crash later in the process. (Better would be to say at the get go, something like: ‘I don’t have any words that match your languages choices’
Also, the above has a highly buried dependency on the user’s setting/pref on whether they want to use the roman version or the non-roman version of languages that have their own special script/alphabets.
So (we’re getting VERY close to the topic of this post) I am currently in the process of improving this process by pulling the user setting dependency out (or at least make it injectable when testing.)
The Point
So I wrote a test, and attempted to run it. But when I ran my single test, with its shiny new injected dependency it never ran, because Xcode first insisted on running my main app, which of course was still crashing when attempting to use the old/broken logic for picking a card.
Thanks to a great answer from the ever helpful Quinn, I was able to discover this setting in Xcode.
Once I set it to None, I was able to run my stand alone test, and resume creating my improved card picking logic.