Weird инициализация синглтона в статической функции инициализации во время блока тестирует

У меня есть следующий код в моем классе одноэлементногоWeird инициализация синглтона в статической функции инициализации во время блока тестирует

static MySingleton *gManager; 
+(void)initialize 
{ 
    if(self == [MySingleton class]) 
    { 
     gManager = [[MySingleton alloc] initWithServices:[[MyServices alloc] init]]; 
    } 
} 
+(MySingleton *)sharedInstance 
{ 
    return (gManager); 
}

К сожалению, в модульных тестах, я вижу, что gManager является экземпляром типа SenTestCaseRun. Кажется, я не понимаю, почему? Итак, звонок вроде [[MySingleton sharedInstance] myFunction];

приводит к ошибке, что myFunction является неизвестным селектором, хотя он существует в классе MySingleton.

Это тип SenTestCaseRun, потому что я проверил функцию NSStringFromClass.

Любые указатели? Уже ударилась головой в течение 3-4 часов на этом :(.

источник

2011-02-22 Nitin Singh

Я не знаю, какой это язык, но на самом деле не похож на 'C' – eckes

Я думаю, что OP напечатал' цель c' в поле тегов. Починил это. –

Его цель C. Я добавил, что в моих тегах. Как я могу сделать это более понятным? –

Установите контрольную точку в +initialize, чтобы убедиться, что эта переменная установлена правильно. Если это не объясняет это, используйте watchpoint чтобы узнать, кто его модифицирует.

источник

2011-02-22 19:53:45

Я пробовал его под отладчиком и единственным местом, где инициализируется глобальный gManager, является во время запуска тестового запуска со следующим стеком вызовов: # 0in + [AudioManager initialize] в AudioManager.m: 118 # 1 в _class_initialize # 2in _class_initialize # 3in prepareForMethodLookup # 4in lookUpMethod # 5in _class_lookupMethodAndLoadCache # 6in objc_msgSend # 7in + [NSObject (SenTestRuntimeUtilities) senAllSubclasses] # 8in + [SenTestSuite updateCache] # 9in + [SenTestSuite suiteForBundleCache] # 10in + [SenTestSuite testSuiteForBundlePath:] # 11in + [SenTestProbe указанныйTestSuite] # 12in + [SenTestProb e runTests:] ' –

Это с точки наблюдения? И он назначается правильному классу в этот момент, но позже падает, потому что это неправильный класс? –

Хорошо, выяснили, что проблема. Я выпустил свой синглтон во время закрытия приложения [[MySingleton sharedInstance]]. Если ссылаться позже, глобальный был случайным экземпляром, установленным средой выполнения. Не имеет смысла выпускать синглтон, но тогда мне нужно было освободить некоторые ресурсы. Поэтому я переработал код. Кстати, мой код хорошо работал на устройстве, но модульные тесты неоднократно вызывали события отключения приложения. –

может быть лучше просто поставить код инициализации внутри общего метода экземпляра

+(MySingleton *)shared 
{ 
    static MySingleton *sharedInstance = nil; 
    if(sharedInstance == nil){ 
     sharedInstance = [[MySingleton alloc] init]; 
    } 
    return sharedInstance; 
}

также в вашем коде вы сравниваете объект в класс, который никогда не будет истинным, вместо сравнения [self class] с [MySingleton class].

источник

2011-02-22 19:37:19

Преимущество версии OP состоит в том, что она является потокобезопасной. В методе класса, например '+ initialize',' self' является классом. –

Weird инициализация синглтона в статической функции инициализации во время блока тестирует

ответ

Смежные вопросы