получение «нераспознанного селектора» при попытке использовать класс, созданный Core Data managed object XCode в модульном тестировании?

#iphone #objective-c #core-data #xcode4 #ocunit

#iPhone #objective-c #core-data #xcode4 #ocunit

Вопрос:

Почему я получаю «нераспознанный селектор» при попытке использовать класс, созданный Core Data managed object XCode в модульном тестировании?

То есть в тестовом примере я должен указать путь к методу, созданному экземпляром объекта, управляемого core data (я использую управляемые объекты, сгенерированные Xcode 4). Чтобы облегчить тест, я мог бы просто создать объект самостоятельно (не используя core data framework). Казалось, все в порядке, однако, когда я пытаюсь использовать свойства, я получаю «нераспознанный селектор».

Вопрос, я думаю:

  1. Почему я получаю этот «нераспознанный селектор»?
  2. Как я могу изменить то, что я делаю, чтобы создать облегченную версию моего объекта core data managed, который будет использоваться в качестве входных данных для тестируемого метода в модульном тестировании?

Пример кода из управляемого объекта. Например, здесь использование свойства «title» может вызвать проблему:

 @interface WEView : NSManagedObject {
  @private
}
  @property (nonatomic, retain) NSString * title;
@end


#import "WEView.h"
@implementation WEView
   @dynamic title;
@end
  

Ответ №1:

@dynamic Команда препроцессора сообщает компилятору, что методы будут предоставлены во время выполнения. Именно контекст управляемого объекта предоставляет методы, основанные на информации, взятой из модели управляемого объекта. Без контекста класс не имеет фактического метода и не может реагировать на селектор.

Комментарии:

1. спасибо TechZen — есть идеи о том, как я могу изменить то, что я делаю, чтобы получить облегченную версию моего объекта core data managed, который будет использоваться в качестве входных данных для тестируемого метода в модульном тестировании? (не касаясь управляемых объектов, сгенерированных xcode)

2. У меня никогда не было особого успеха в тестировании на заглушках. В конечном итоге вы просто создаете маленькие поддельные средства доступа, которые не обязательно воспроизводят поведение реальных объектов.

3. Я предпочитаю работать с полноценным стеком Core Data в рамках выделенного проекта тестирования, т. Е. я переношу модель данных и классы в их собственный проект, а затем просто генерирую данные и провожу тестирование там. Я думаю, это необходимо, потому что граф объектов является настоящим сердцем Core Data, и именно в нем также обнаруживаются незначительные ошибки. Если у вас нет реалистично большого графика объектов, то вы действительно не сможете протестировать все. Делать это утомительно, но это дает наилучшие результаты. Когда вы уверены, что модель данных работает должным образом, у вас есть истинное нутро вашего приложения.

4. однако, что вы делаете для повторного тестирования в своем приложении (не coredata component)? т. Е. когда вы получаете объекты core data из своих методов core data (которые находятся в их собственном проекте), вы передаете их через свое приложение? В этом случае тестирование самого вашего приложения также потребует от вас использования реальных классов core data, я полагаю? (или, возможно, как только вы получите объект core data, вы скопируете его значения в класс, отличный от coredata, для использования в самом приложении?)…

5. Да, я использую реальный стек Core Data с помеченной фиктивной информацией на протяжении всей разработки. Как только модель данных установлена, приложение готово на 80%. Тестирование не особенно полезно при работе с пользовательским интерфейсом из-за количества перестановок ввода пользовательского интерфейса. Итак, я концентрируюсь на тестировании модели данных.