TyphoonPatcher для мокинга в юнит-тестах

Вот несколько дополнительных советов по поводу основного ответа. . .

Модульные тесты и интеграционные тесты:

В Typhoon мы придерживаемся традиционных терминов:

• Модульные тесты: тестирование вашего класса отдельно от соавторов. Здесь вы вводите дубликаты тестов, такие как макеты или заглушки, вместо всех реальных зависимостей.

• Интеграционные тесты: тестирование вашего класса с участием реальных соавторов. Хотя вы можете пропатчить наш компонент, чтобы привести систему в состояние, необходимое для этого теста.

Таким образом, любой тест, использующий TyphoonPatcher, вероятно, будет интеграционным тестом.

Подробнее здесь: Тестирование интеграции с Typhoon

Разрешение совместных сборок:

Это требовалось в более ранней версии Typhoon, но больше не требуется. Любые свойства, являющиеся подклассом TyphoonAssembly, будут рассматриваться как взаимодействующие сборки. Удалите следующее:

- (void)resolveCollaboratingAssemblies
{
    _services = [TyphoonCollaboratingAssemblyProxy proxy];
    _models = [TyphoonCollaboratingAssemblyProxy proxy];
}

Тесты создают свою собственную сборку:

Мы рекомендуем, чтобы тесты создавали экземпляры и удаляли их на TyphoonComponentFactory. Преимущества:

• [TyphoonComponentFactory defaultFactory] является глобальным и имеет некоторые недостатки.
• Интеграционные тесты могут определять свои собственные исправления, не беспокоясь о возвращении системы в исходное состояние.
• Помимо использования TyphoonPatcher, при желании вы можете создать сборку, в которой определения некоторых компонентов переопределены.

Вы столкнулись с плохим выбором дизайна со стороны Typhoon, но есть простой обходной путь.

Вы используете этот метод:

[patcher patchDefinition:[ui choiceController] withObject:^id{
   return mock([MDChoiceViewController class]);
}];

. . который ожидает TyphoonDefinition в качестве аргумента. При загрузке Тайфуна:

• Мы начинаем с одного или более TyphoonAssembly подклассов, которые Тайфун использует для получения рецептов для строительных компонентов. Затем эти TyphoonAssembly подклассы отбрасываются.
• Теперь у нас есть TyphoonComponentFactory, который позволит любому из ваших TyphoonAssembly интерфейсов позировать перед ним. (Это сделано для того, чтобы вы могли иметь несколько конфигураций одного и того же класса, избегая при этом магических строк, разрешая автозаполнение в вашей среде IDE и т. д.).

Когда TyphoonPatcher был написан, он был разработан для случая, когда вы получаете новый TyphoonComponentFactory для своих тестов (рекомендуется), например:

//This is an actual TyphoonAssembly not the factory posing as an assembly
MiddleAgesAssembly* assembly = [MiddleAgesAssembly assembly];

TyphoonComponentFactory* factory = [TyphoonBlockComponentFactory factoryWithAssembly:assembly];

TyphoonPatcher* patcher = [[TyphoonPatcher alloc] init];
[patcher patchDefinition:[assembly knight] withObject:^id
{
    Knight* mockKnight = mock([Knight class]);
    [given([mockKnight favoriteDamsels]) willReturn:@[
        @"Mary",
        @"Janezzz"
    ]];

    return mockKnight;
}];

[factory attachPostProcessor:patcher];
Knight* knight = [(MiddleAgesAssembly*) factory knight];

Что произошло:

Итак, проблема в том, что TyphoonPatcher ожидает TyphoonDefinition от TyphoonAssembly, а вместо этого получает фактический компонент от TyphoonComponentFactory.

Очень запутанно, и этот способ получения патчера должен быть объявлен устаревшим.

Решение:

Вместо этого используйте следующее:

[patcher patchDefinitionWithSelector:@selector(myController) withObject:^id{
     return myFakeController;
}];