Open Radar

 
Summary:
Setting a TEST_RIG is pointless, as it is never honoured by Xcode. Instead, Xcode always runs otest.

Steps to Reproduce:
1. Make a new project for an app, command-line tool, framework, or library; I’m using the built-in Cocoa templates for my new projects.
2. Add a unit testing bundle.
3. Set its TEST_RIG build setting to anything other than otest.

Expected Results:
I expected Xcode to run my TEST_RIG and for it to receive the relevant build settings (TEST_HOST, PRODUCT_NAME, etc, as specified in the build settings and as described in the Quick Help documentation for TEST_RIG; see Notes for more).

Actual Results:
Instead, it just runs otest, which is not the desired test rig, and which does not function correctly.

Regression:
Xcode 3 handled this correctly.

Notes:
Quick Help has this to say about TEST_RIG:

“Path to a unit testing tool to use. The tool can take information from its environment and it will be passed the contents of the Other Test Flags build setting as its first few arguments, and the path to a unit test bundle as its final argument. Only specify this setting if using a custom test rig.”

This is one of several issues making it difficult for me to integrate my unit testing tool with Xcode. I would like to be able to run an arbitrary TEST_RIG with an arbitrary test bundle and produce test results in an OCUnit-compatible format such that Xcode can show them prettily. This functions—but only sometimes!—when I instead set TEST_HOST to my test rig and provide arguments in the scheme such that it is able to find the thing to test; but that only functions correctly when the test rig is built by Xcode, not when it’s been provided and e.g. lives in /usr/local/bin or $(SRCROOT).