isKindOfClass returning NO unexpectedly

Question

One of my unit tests is failing and for a reason I didn't anticipate. It seems a call to isKindOfClass is returning NO, but when I debug and step through, there seems to be no reason it would.

The code is:

if ([self.detailItem isKindOfClass:[MovieInfo class]]) {
    [self configureViewForMovie];
}

I stepped through the code and did:

po self.detailItem

which displays:

(id) $1 = 0x0ea8f390 <MovieInfo: 0xea8f390>

So, what am I missing, why would the if statement return false in this case?

EDIT:

Here is the setter for the DetailItem:

- (void)setDetailItem:(id)newDetailItem
{
    if (_detailItem != newDetailItem) {
        NSLog(@"%@", [newDetailItem class]);
        _detailItem = newDetailItem;

        // Update the view.
        [self configureView];
    }

    if (self.masterPopoverController != nil) {
        [self.masterPopoverController dismissPopoverAnimated:YES];
    } 
}

It's template code from a Master Detail template.

The unit test creates a MovieInfo in setUp:

movie = [[MovieInfo alloc] initWithMovieName:@"Movie" movieID:1];

and sets it in the test

controller.detailItem = movie;

Additionally, I added a parameter assertion in setDetailItem:

NSParameterAssert([newDetailItem isKindOfClass:[MovieInfo class]] || [newDetailItem isKindOfClass:[PersonInfo class]] || newDetailItem == nil);

This assertion is failing as well.

I've put two log statements above the assertion call:

NSLog(@"%@", [newDetailItem class]);
NSLog(@"%@", newDetailItem);

which display:

2012-08-28 08:31:37.574 Popcorn[8006:c07] MovieInfo
2012-08-28 08:31:38.253 Popcorn[8006:c07] <MovieInfo: 0x6daac50>

ONE MORE EDIT:

I added the isKindOfClass check before setting it in the unit test, that one passes.

if ([movie isKindOfClass:[MovieInfo class]]) {
    NSLog(@"Yep"); //This passes and prints out
}
controller.detailItem = movie; //calls into the setter and fails.

Answer 1

This was due to the fact that the class under test "DetailViewController" was not in the test's target. I would have expected this to manifest itself in a different way (linker error or something), but apparently, it just causes odd behavior. Adding DetailViewController to the test target fixed the issues.

Answer 2

I would suspect a race condition, or a different between Debug and Release configurations. These will lead to differences between the debugger and regular runtime.

First, make sure that self.detailItem isn't nil. That's the most common cause of this kind of issue. Then try debugging this with logging rather than the debugger. If you really do have race conditions, then you may also consider logging with printf() rather than NSLog(). printf() is a much less performance-impacting way to do multi-threaded logging.