views:

23

answers:

1

I'm currently writing an Objective-C class which has a relatively complex method in its interface. For the purpose of the question, I'll use the following declaration...

@interface Processor : NSObject {

}

- (NSObject*)doSomeComplicatedProcessing:(NSObject*)param;

@end

So doSomeComplicatedProcessing is my complicated method. In my implementation of doSomeComplicatedProcessing I invoke a series of other methods which are declared and implemented in Processor.m (i.e. they are not part of the interface). The methods are not part of the interface as they are used solely in the implementation of doSomeComplicatedProcessing and would not be of use to clients of Processor.

I'm wondering what the best practice is for testing these methods? Obviously I can test doSomeComplicatedProcessing as a whole, but what if I want to test the non-interface methods?

I currently invoke these methods and ignore the compiler warning me that Processor 'may not implement method someMethodName', but it leaves me feeling a little dirty. Is there a best practice for Objective-C around this problem?

+1  A: 

You could pull the declarations out in a seperate header, say Processor+Private.h, which only Processor.m and test code use.
Although i wonder wether you can hold up the invariants for these private methods when calling them seperately from the outside.

Georg Fritzsche
The invariants for the non-exposed methods do actually hold - though it's a very valid point and it would probably be true in most other scenarios similar to this.I'm going to use your suggestion - thanks!
mmccomb