Тестовый код с вызовами dispatch_async

Есть два основных подхода. Либо

• Делайте вещи синхронными только во время тестирования. Или,
• Держите вещи асинхронными, но напишите приемочный тест, который выполняет повторную синхронизацию.

Чтобы сделать вещи синхронными только для тестирования, извлеките код, который действительно работает, в их собственные методы. У вас уже есть -filteredDataWithText:. Вот еще извлечение:

- (void)updateTableWithFilteredData:(NSArray *)filteredData
{
    self.filteredData = filteredData;
    [self.tableView reloadData];
}

Настоящий метод, который заботится обо всех потоках, теперь выглядит так:

- (void)searchBar:(UISearchBar *)searchBar textDidChange:(NSString *)searchText
{
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        NSArray *filteredData = [self filteredDataWithText:searchText];

        dispatch_async(dispatch_get_main_queue(), ^{
            [self updateTableWithFilteredData:filteredData];
        });
    });
}

Обратите внимание, что под всей этой причудливостью потоков он на самом деле просто вызывает два метода. Итак, теперь, чтобы сделать вид, что все потоки выполнены, пусть ваши тесты просто вызывают эти два метода по порядку:

NSArray *filteredData = [self filteredDataWithText:searchText];
[self updateTableWithFilteredData:filteredData];

Это означает, что -searchBar:textDidChange: не будет охватывать модульные тесты. Один ручной тест может подтвердить, что он отправляет правильные вещи.

Если вам действительно нужен автоматизированный тест для метода делегата, напишите приемочный тест с собственным циклом выполнения. См. Шаблон для модульного тестирования асинхронной очереди, вызывает основную очередь по завершении. (Но держите приемочные тесты в отдельной тестовой цели. Они слишком медленные, чтобы включать их в модульные тесты.)

Параметры Albite Jons в большинстве случаев очень хороши, иногда они создают менее загроможденный код при выполнении следующих действий. Например, если в вашем API много мелких методов, которые синхронизируются с помощью очереди отправки.

Имейте такую ​​​​функцию (это может быть и метод вашего класса).

void dispatch(dispatch_queue_t queue, void (^block)())
{
    if(queue)
    {
        dispatch_async(queue, block);
    }
    else
    {
        block();
    }
}

Затем используйте эту функцию для вызова блоков в ваших методах API.

- (void)anAPIMethod
{
    dispatch(dispQueue, ^
    {
        // dispatched code here
    });
}

Обычно вы инициализируете очередь в своем методе init.

@implementation MyAPI
{
    dispatch_queue_t dispQueue;
}

- (instancetype)init
{
    self = [super init];
    if (self)
    {
        dispQueue = dispatch_queue_create("myQueue", DISPATCH_QUEUE_SERIAL);
    }

    return self;
}

Затем используйте такой частный метод, чтобы установить эту очередь в ноль. Это не часть вашего интерфейса, потребитель API никогда этого не увидит.

- (void) disableGCD
{
    dispQueue = nil;
}

В вашей тестовой цели вы создаете категорию, чтобы выставить метод отключения GCD:

@interface TTBLocationBasedTrackStore (Testing)
- (void) disableGCD;
@end

Вы вызываете это в своей тестовой настройке, и ваши блоки будут вызываться напрямую.

Преимуществом в моих глазах является отладка. Когда тестовый пример включает в себя цикл выполнения, так что блоки фактически вызываются, проблема заключается в том, что должен быть задействован тайм-аут. Этот тайм-аут обычно довольно короткий, потому что вы не хотите, чтобы тесты длились долго, если они заканчиваются тайм-аутом. Но короткий тайм-аут означает, что ваш тест истечет тайм-аут при отладке.