isKindOfClass returning NO unexpectedly

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.

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.

I had this same issue in a library that I am writing. Funnily enough, it worked fine on my iOS test target, but failed on the Mac test target (interesting!).

I believe the issue is related to a mismatch in the class declarations. The library is using the .h declaration but the unit tests were looking at the internal declarations.

It's easier to explain with an example:

/*
 * ClassA.h
 */
@interface ClassA () : NSObject

@property (nonatomic, strong, readonly) NSString *someValue1;
@property (nonatomic, strong, readonly) NSString *someValue2;
@property (nonatomic, strong, readonly) NSString *someValue3;

@end

Adding to the property list in the .m

/*
 * ClassA.m
 */
@interface ClassA () : NSObject

@property (nonatomic, strong, readwrite) NSString *someValue2;
@property (nonatomic, strong, readwrite) NSDate *date;
@property (nonatomic, strong, readwrite) NSDateFormatter *dateFormatter;

@end

@implementation 
// implementation
@end

Now, since the unit test targets had the compile sources set to include ClassA.m, the isKindOfClass: would return no, but po command and NSStringFromClass([ClassA class]) when run in the debugger would return values that you expect.

I know this is an old post, but I hope this is useful and saves someone a lot of time. Took me almost an hour trying to figure this issue out!

MarkPowell's answer does help absolutely, if you want to always add all of your source files to all of your test targets.

However, if you have your Application as target dependency of your test target (if you are having only the test source files in your test target, not the project source files), then you have the same problem I had: One of your classes should be in the App target and NOT the test target (in my case it was a test helper class!)