Extended OCMockObject with verifyWithDelay that takes a timeout.

[dblock]

How do you feel about adding a verifyWithDelay? It could of course be made into a separate pod (I will if you don't like this), but I think it makes sense to make it easy for users of OCMock as it's, IMO, a pretty common scenario.

It looks like everybody is rolling out their own mock with delay. In our project we have lots of callback asynchrony going on and eventually it results in some dialog popup.

This is code from https://gist.github.com/CharlesHarley/7411681, cc: @CharlesHarley.

This btw is also motivation for implementing Expecta expectations (see specta/expecta#71), which has a .will. that basically does the same thing more generically.

[dblock]

cc: @CharlesHarley, had wrong name in there ...

[LowAmmo]

Might be worth it to extend this logic to just flush everything on the queue (if you don't want to be hampered by a time delay):

@implementation NSRunLoop (TestUtilities)

- (void)flushQueue:(NSTimeInterval)maxSecondsToWait
{
    __block dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);

    __block BOOL queueCleared = FALSE;
    dispatch_async(dispatch_get_main_queue(), ^(void){
        queueCleared = TRUE;
        dispatch_semaphore_signal(semaphore);
    });

    while(dispatch_semaphore_wait(semaphore, DISPATCH_TIME_NOW))
    {
        @try
        {
            [self runMode:NSDefaultRunLoopMode beforeDate:[NSDate dateWithTimeIntervalSinceNow:MAX_RUNLOOP_WAIT_SECONDS]];
        }
        @catch (NSException *exception)
        {
            NSLog(@"Exception While Flushing Run Loop: %@", exception.description);
        }
    }

    [self runUntilDate:[NSDate dateWithTimeIntervalSinceNow:maxSecondsToWait]];
}

@end

[dblock]

Bump. LMK if you want me to do any of these things to get this merged. It's probably a good idea, but I'd want to make it a separate PR.

[erikdoe]

Still curious about LowAmmo's comment. Do you really mean to flush the events in the run loop? Or is the code above just waiting the minimum amount of time after all the events have been processed?

[LowAmmo]

@erikdoe - yes, the intent is to flush everything currently queued up on the current run queue. The extra 'runUntilDate', is just to ensure it doesn't take more than the maximum amount of time... Ideally...would lean towards not having that.. But I debate back and forth on that.