Tired of getting Mach-O Linker errors when unit testing?

It seems like every time a new feature gets checked in, somebody fails to add it to the test target, and I get a linker error like this one:

Apple Mach-O Linker (ld) Error: _OBJC_CLASS_$_CLASSNAME referenced from…

The solution to this is not to just keep adding files to the test target.  If you compile a source file both into your test target and your app target, you are compiling the same code twice.  While on the surface this doesn’t sound so bad, in fact it can be:

Class MYCLASSNAME is implemented in both EpicPath1 EpicPath2. One of the two will be used. Which one is undefined.

This doesn’t sound so bad either, if you take a conservative view of “One of the two will be used”.  After all, they’re both the same class.  Apple, however, has quite a more whimsical outlook on things.  Which class definition is used can change many times within a single compilation unit.  So if you do something like this:

@implementation MYCLASSNAME

static BOOL mysharedVariable = NO;

+ (void) setMySharedVariable:(BOOL) value {mySharedVariable = value; }

+ (void) test
{
   [self setMySharedVariable:YES];
   NSLog(@"%d",mySharedVariable); //prints 0 or 1 with ~50% probability
}

It really gets surreal when you set the variable in one function, and you read it two functions deeper in the stack.  Set your debugging context to the inner function, it returns 0.  Set your debugging context to the outer function, it returns 1.  Then you wonder if you will look back on the debugging session as the time when the voices started.

So what you should actually do is this:

1. Get everything that’s not a unit test out of the unit test target.  No more application code in there.
2. Set BUNDLE_LOADER=$(BUILT_PRODUCTS_DIR)/myapp.app/myapp
3. Set TEST_HOST=$(BUNDLE_LOADER)
4. ensure “Symbols hidden by default” is NO in your app target (not your test target).  This lets the linker reach into the application bundle and use its symbols in your test target.  Depending on how serious you are about preventing reverse-engineering, you might want to turn this to YES for release builds.