Тесты функций с KIF: beforeEach вызывается после загрузки моего контроллера представления?

Тесты, которые зависят от цели (например, KIF и некоторые модульные тесты), запускаются после запуска приложения, поэтому нет, вы не можете заставить beforeEach идти перед вашим AppDelegate без какого-либо ужасного хакерства.

Я не знаю, как вы делаете внедрение зависимостей, поэтому вот как мы это делаем/некоторые общие стратегии.

В идеале тесты KIF не должны имитировать уровень кода

Это связано с тем, что KIF является своего рода альтернативой UIAutomation и в основном полезен для функциональных/функциональных тестов на уровне пользовательского интерфейса. Вы действительно не хотите так сильно менять код своего приложения. Мок лучше всего достигается с помощью фреймворков, таких как OHHTTPStubs для сети или OCMock для объектов, и они лучше всего работают, когда ограничены модульными тестами.

Как имитировать сетевые запросы в «настоящем» приложении

Лучший способ здесь — использовать что-то вроде OHHTTPStubs или сервера AMY (созданного теми же людьми, что и KIF) или Nocilla для возврата ответов-заглушек. Таким образом, вы можете позволить вашему коду приложения работать полностью. OHHTTPStubs, например, использует NSURLProtocol для перехвата ваших запросов, поэтому с точки зрения приложения это почти так же хорошо, как выход в сеть.

Я действительно хочу смоделировать эти объекты

Если вы действительно действительно хотите смоделировать объекты, внедренные зависимостями, с разными объектами, то есть несколько более и менее хакерских вариантов.

1) Используйте реальную структуру DI (или создайте свою собственную), которая позволяет исправлять зависимости. Я использовал Тайфун, и это разумно. Стандартная идея здесь — использовать инверсию управления в своих интересах. Поскольку вы получаете все свои объекты из контекста приложения, а не напрямую, гораздо проще настроить уровень абстракции контекста приложения. У Typhoon даже есть вики-страница на эту тему: https://github.com/appsquickly/Typhoon/wiki/Integration-Testing

2) Отследите источник объекта, который вы вводите, и хотите смоделировать и изменить его в источнике. Это не самое элегантное решение, и вы все равно как бы взламываете инфраструктуру DI, но, возможно, у вас недостаточно времени или сложности, чтобы оправдать переход на инфраструктуру DI.

3) Взломайте все до верхнего уровня. Имейте тестовый AppDelegate, который является подклассом вашего обычного AppDelegate, и используйте его во время тестирования KIF (и, конечно же, заглушайте или имитируйте объекты, которые вы хотите). Это не гибко, но опять же, может быть, вам просто нужен один тестовый пример или что-то в этом роде:

int main(int argc, char *argv[])
{
    int returnValue;
    @autoreleasepool {
        BOOL inIntegrationTests = NSClassFromString(@"KIFTestCase") != nil;
        if (inIntegrationTests) {
            returnValue = UIApplicationMain(argc, argv, nil, @"AppDelegateForTest");
        }
        else {
            returnValue = UIApplicationMain(argc, argv, nil, @"AppDelegate");
        }
    }
    return returnValue;
}

В конечном счете, к сожалению, это не простой вопрос «куда мне поставить этот метод».