Тестирование объекта NSURLConnection Mock против реализации

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

У меня есть RequestObject, который является подклассом NSOperation.


@interface RequestOperation : NSOperation

@property (nonatomic, strong) NSURLRequest *URLRequest;
@property (nonatomic, strong, readonly) NSURLResponse *URLResponse;
@property (nonatomic, strong, readonly) NSError *connectionError;
@property (nonatomic, strong, readonly) NSData *responseData;

-(id)initWithURLRequest:(NSURLRequest*)request;

@end

В реализации у меня есть частная категория с NSURLConnection.

Я хочу написать тестовый пример, чтобы проверить, существует ли URLResponse после отправки запроса.


-(void)testIfResponseExist
{
    NSURL *url = [[NSURL alloc] initWithString:@"https://google.com"];
    NSURLRequest  *request = [[NSURLRequest alloc] initWithURL:url];

    myRequest = [[RequestOperation alloc] initWithURLRequest:request];
    [myRequest start];

    [self WaitFor:1];

    XCTAssertNotNil(myRequest.URLResponse, @"Response should not be nil");
}

Является ли этот способ модульного тестирования правильным?

Теперь это отправка фактического запроса на сервер. Однако я также могу заглушить NSURLConnection и отправить фиктивный ответ. Но я не уверен, каким путем мне идти. Каковы плюсы и минусы фиктивного объекта?


ios unit-testing xctest ocmock
person Kunal Balani    schedule 02.06.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Ваш тест кажется правильным для тестирования библиотеки, но я считаю, что объекты Mocking больше подходят для тестирования приложений. Вы не захотите делать насмешки для тестовых слепков вашей библиотеки, а скорее для тестовых случаев в своем приложении, которые используют вашу библиотеку.

Я приведу вам пример мощности фиктивного объекта с модульным тестированием.

Я только что помог написать автоматизированный фреймворк для загруженного iOS-приложения. Мы использовали OCMock и KiF для автоматизации обновлений содержимого приложения. В нашем автоматизированном тесте мы используем тот же точный код, что и приложение для обновления содержимого. Однако мы OCMock используем метод, который возвращает URL-адрес контента, и заставляем его возвращать другой. Это очень похоже на swizzling. Теперь приложение будет указывать на наш тестовый URL-адрес для загрузки обновлений контента при тестировании. С помощью 1-2 строк кода мы заменили URL-адрес без необходимости писать какой-либо собственный код.

id mock = [OCMockObject mockForClass:[MasterUpdater class]];
[[[mock stub] andReturn:[NSString stringWithFormat:@"URL",BASE_UPDATE_TEST_URL]] getMasterUpdateURL];

При этом MasterUpdater:getMasterUpdateURL возвращал пользовательский URL. Это все, что нам нужно было сделать в нашем модульном тесте, чтобы переключить URL-адрес для наших автоматических тестов!

Если бы мы не использовали насмешки, то мы бы написали дополнительный код/методы в нашем производственном коде для обработки нашего автоматизированного теста.

person LyricalPanda    schedule 02.06.2014