Запустить логические тесты в Xcode 4 без запуска симулятора

Ответ 1

Пожалуйста, кто-нибудь скажет мне, как проверить, не проверили ли все тестовое оборудование? Мое приложение управляется событиями, и он отправляет кучу событий, когда он запускает этот беспорядок с моими тестами.

Я использую встроенное тестирование Xcode 4. Создание экземпляра приложения может показаться болью, но, как я пишу на Xcode Unit Testing: The Good, the Bad, the Ugly, он позволяет писать тесты, не различая логические тесты и тесты приложений. В частности, он позволяет мне писать модульные тесты для контроллеров представлений.

Вот что я делаю, чтобы избежать моей полной последовательности запуска:

Редактировать схему

• Выберите тестовое действие
• В "Тесте" выберите вкладку "Аргументы"
• Отключить "Использовать параметры запуска"
• Добавьте переменную окружения, установив runningTests в YES

Отредактируйте делегат приложения

• Добавьте в -application:didFinishLaunchingWithOptions: как только имеет смысл:

  #if DEBUG
      if (getenv("runningTests"))
          return YES;
  #endif
  

• Сделайте то же самое для -applicationDidBecomeActive: но просто return.

Обновление: я изменил свой подход. См. Как легко переключить делегат приложения для тестирования.

Ответ 2

В последней версии xcode (5.0.2) вы можете сделать это очень просто. Выберите тестовую цель, вкладку "Общие". Установите "Нет" в поле "Цель". Затем нажмите вкладку "Сроки выполнения" и удалите основную цель из "Зависимости целей".

Ответ 3

В вашей ситуации я предполагаю, что у вас есть отдельная целевая программа Logic Tests and Application Tests (если нет - вам нужно). В конфигурации ваших схем вы определяете, какие цели создаются для схемы "Тест". Если ваши тесты приложений не запущены, симулятор не запускается.

Я подозреваю, что вы можете запускать "логические тесты" в целевом "Тесте приложений" (например, тот, который был создан по умолчанию Xcode). Подробнее об этом различии здесь (и как установить ut up).

Ответ 4

В более раннем ответе было указано, что логические тесты - это правильная вещь для этого сценария. У меня было очень трудное время, чтобы логические тесты работали с XCode Version 4.3.2 (4E2002). Глядя на образец Apple unit test проект, помог мне понять, как это сделать с четким разделением. В этом примере логические тесты проверяют файлы из целевого объекта библиотеки, а не целевую программу. Модель была инкапсулирована в библиотеку, которая затем была связана с основной целью и логическими целями тестирования. Цель приложения содержала только представления и контроллеры.

Основываясь на этой модели, это то, что я сделал, чтобы мои логические тесты работали правильно. Создайте новую цель (Cocoa Touch Static Library) и переместите все файлы, которые будут протестированы логикой (как правило, все ваши модели) для этой новой цели. В настройках "Сборка фаз" добавьте эту новую библиотеку в "Связывание двоичных файлов с библиотеками" целевого целевого объекта и логических тестов.

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

Ответ 5

Обратите внимание: не протестирован на Xcode 5.

Я использовал ответ @jon-reids, но обнаружил, что Xcode добавляет переменные среды в xcuserstated часть XcodeProjects, и они специфичны для пользователя и обычно не привязаны к репозиторию. Таким образом, я переопределяю AppDelegate чтобы переопределить его загрузку:

@implementation MyAppDelegate (Testing)

+ (void)initialize {
    SEL new = @selector(application:didFinishLaunchingWithOptions:);
    SEL orig = @selector(swizzled_application:didFinishLaunchingWithOptions:);
    Class c = [self class];
    Method origMethod = class_getInstanceMethod(c, orig);
    Method newMethod = class_getInstanceMethod(c, new);

    if (class_addMethod(c, orig, method_getImplementation(newMethod), method_getTypeEncoding(newMethod))) {
        class_replaceMethod(c, new, method_getImplementation(origMethod), method_getTypeEncoding(origMethod));
    } else {
        method_exchangeImplementations(origMethod, newMethod);
    }
}

- (BOOL)swizzled_application:(id)app didFinishLaunchingWithOptions:(id)opts {
    return YES;
}

@end

Обратите внимание, что следующее проще и по-прежнему работает, хотя я не уверен, что он надежный:

@implementation MyAppDelegate (Testing)

- (BOOL)application:(id)app didFinishLaunchingWithOptions:(id)opts {
    return YES;
}

@end

Это работает, потому что категории методов в динамически загружаемых компонентах (например, тестовый комплект) имеют приоритет. Swizzling чувствует себя безопаснее.

Ответ 6

Использование xCode 7 и xctool

xctool способен выполнять единичные тесты без симулятора.

Чтобы сделать это,

1. Обновление целевых настроек выполняется без хост-приложения.

Выберите свой проект → затем проверьте цель → Установите для хост-приложения значение none.

2. Установите xctool, если у вас его нет.

brew install xctool

3. Запустите тесты с помощью терминала с помощью xctool.

 xctool -workspace yourWorkspace.xcworkspace -scheme yourScheme run-tests -sdk iphonesimulator

Ответ 7

Я использовал GHUnit для создания совместимых с osx/ios наборов тестов. есть несколько проблем, но я обнаружил, что он более надежный/совместимый/простой, чем OCUnit.

GHUnit предоставляет базовые проекты шаблонов для OS X и iOS, что упрощает первоначальную настройку.

Примечание. Обычно я использую свой собственный набор для большей части моего тестирования.