views:

70

answers:

1

(Let's assume that I have good reasons not to remove my NSAssert() checks in my code just because I'm also doing Unit testing.)

In my unit testing code, I like to make sure that a NSAssert in my code hits (asserts) when I invoke it. I therefore use the STAssertThrows() macro when calling the code that does the assertion.

The problem is: Despite the documentation saying that NSAssert would throw an exception, the unit test run will stop with an error msg saying the the app crashed.

This is with SDK 3.1.3 in the Simulator.

Is this a bug in the framework or is there something I can do to make this work better, i.e. so that NSAssert throws a proper exception that the unit test macro can catch?

A: 

I shot too fast.

Turns out that the problem was somewhere else:

The class which contained the NSAssert that fired was not a subclass of NSOject. This was OK until now because it only contained class methods, no instance methods. But when NSAssert hits, it wants to get the class name of the code it's sitting in, and that method was missing. Making this class a subclass of NSObject fixed it, and now NSAssert does indeed throw an exception which can be tested by STAssertThrows.

I found this out by looking at the warnings in the unit testing log right before the crash: It warned that it could not find methodSignatureForSelector and doesNotRecognizeSelector. After adding these and printing out the selector they're looking for (NSLog(@"sel:%s", aSelector);), I found that it was looking for the "class" method. Then I realized what was going on.

So, while this was a moot question, I hope that at least this explanation is helping someone someday, perhaps :)

I don't mind having this q deleted, though, either.

Thomas Tempelmann