Update 2017
skypecakes mentions in the comments:
For anyone using XCode 8 and higher: xctool is no longer supported, and does not work.
Use xcodebuild instead.
Original answer (2013)
You can check this tutorial, which explains:
xctool is an excellent choice for running your tests under a continuous integration server such as Travis CI or Jenkins.
In order to your run your tests within a continuous integration environment, you must create Shared Schemes for your application target and ensure that all dependencies (such as CocoaPods) are added explicitly to the Scheme.
To do so:
- Open up the Manage Schemes sheet by selecting the Product menu > Schemes > Manage Schemes...
- Locate your application target in the list. Ensure that the Shared checkbox in far right hand column of the sheet is checked.
- If your application or test targets include cross-project dependencies such as CocoaPods, then you will need to ensure that they have been configured as explicit dependencies. To do so:
- Highlight your application target and hit the Edit... button to open the Scheme editing sheet.
- Click the Build tab in the left-hand panel of the Scheme editor.
- Click the + button and add each dependency to the project. CocoaPods will appears as static library named Pods.
- Drag the dependency above your application target so that it is built first.
You will now have a new file in the xcshareddata/xcschemes directory underneath your Xcode project.
This is the shared Scheme that you just configured.
Check this file into your repository and xctool will be able to find and execute your tests on the next CI build.
For more flexibility, you can also control how Travis installs and invokes xctool:
language: objective-c
before_install:
- brew update
- brew install xctool
script: xctool -workspace MyApp.xcworkspace -scheme MyApp test
That last configuration is similar to the approach illustrated in this other tutorial:
Once you have linked your repo the next step would be to add a .travis.yml file to the root of the repo.
language: objective-c
before_script: travis/before_script.sh
script: travis/script.sh
- First I’m telling Travis that this is an objective-c project.
- Next I tell Travis how I’d like it to do CI against this repo by giving it instructions on what scripts it should run in order to actually perform a build.
I also give some extra instructions on what to do just prior to running a build.
It’s quite common to put all the build steps inline right in the .travis.yml file, but I prefer to actually create bash scripts in my repo inside a travis directory in my git repo and then just refer to those scripts from my .travis.yml.
This keeps the .yml file nice and small, and also makes it easy for me to test the travis build scripts locally.
We gave Travis a before_script in the .yml file above. This is intended to be used by the Travis agent to download tools needed as part of the build. Here’s what it looks like:
travis/before_script.sh
#!/bin/sh
set -e
brew update
brew install xctool
Very simple. We just use homebrew to install xctool on the build agent.
All travis build agents come with homebrew pre-installed, but sometimes the formula aren’t up to date, so it’s best to run a brew update before attempting a brew install.
That’s all we need to do to prepare our agent for the build.
Next let’s look at the build script itself:
travis/script.sh
#!/bin/sh
set -e
xctool -workspace MyWorkspace -scheme MyScheme build test
Again, this is really simple.
We first do a basic sanity check by asking xctool to build our app, specifying a workspace and scheme.
This just checks that we don’t have any compilation errors.
Assuming that succeeds xctool will then build and run the unit testing target for our app, launching the Simulator on the Travis agent if needed.
