Reputation:
I have a number of logic unit-tests (where my project files have a target membership of the App and AppTests). I want to add a call to xcodebuild test-without-building to my build system so that my unit-tests run for each build.
However, the tests cannot run on the release build (because release doesn't build for testing).
Is my only choice to build both the release version and the debug version during my build, so that I can use the debug version only to perform the tests? That's very different and very much worse to the other test frameworks I've used (GTest, Catch). Why can't the tests stand on their own?
Upvotes: 2
Views: 2146
Reputation: 17491
The test-without-building
command is not actually meant to "run the tests without rebuilding the app", but rather it's supposed to be used in tandem with the build-for-testing
command.
Please refer to the "Advanced Testing and Continuous Integration" WWDC 2016 session for more info.
The gist is: use build-for-testing
to build an .xctestrun
file, which is then used by test-without-building
to run the tests. This is particularly useful to run big suites across different machines, although I have never done it myself.
Now that we have established that you can't use test-without-building
on its own, the only option to run the test from the command line and if they pass build a Release
version is to use xcodebuild test
, which is going to build the app.
As for the why does it need to be in Debug
, I don't have a precise answer. In iOS land, at least in the teams I worked with, the difference between Debug
and Release
builds is always only on things like the options passed to the compiler in terms of optimization, the architectures to build on, and the type of code signing.
This means that the code that runs in Debug
vs Release
is exactly the same, and since we already established that you'll need to build the app twice, one to run the tests, one to generate the releasable version, running the tests in Debug
seems acceptable.
Upvotes: 3