Рекомендации по тестированию слоя запроса API в приложениях iOS с использованием NSOperations и Coredata

Я разрабатываю приложение iOS, которое использует REST API. Приложение iOS запрашивает данные в рабочих потоках и сохраняет анализируемые результаты в основных данных. Все представления используют основные данные для визуализации информации. REST API быстро меняется, и я не имею никакого реального контроля над интерфейсом.

Я ищу советы, как максимально упростить интеграционные тесты для приложения. Должен ли я тестировать API или данные Mock? Но как правильно высмеивать GET-запросы, если вы можете создавать ресурсы с помощью POST или изменять их с помощью PUT?

Какие рамки вы используете для подобных проблем? Я играл с Frank, который выглядит неплохо, но усложняется из-за быстрых изменений пользовательского интерфейса в приложении iOS. Как бы вы протестировали "слой запроса API" в приложении? Рабочие потоки - это NSOperations в очереди - все строит асинхронно. Любые рекомендации?

ОТВЕТЫ

Ответ 1

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

Как насмехаться над сервером, для unit test, который делает это:

first_results = list_things()
delete_first_thing()
results_after_delete = list_thing()

У меня есть макет структуры данных, которая выглядит так:

{ list_things_request : [first_results, results_after_delete], 
  delete_thing_request: [delete_thing_response] }

Он запрограммирован на ваш запрос, и значение представляет собой массив ответов для этого запроса в том порядке, в котором они были замечены. Таким образом, вы можете многократно поддерживать один и тот же запрос (например, перечислять вещи) и получать другой результат. Я использую этот формат, потому что в моей ситуации мои вызовы API могут выполняться в несколько ином порядке, чем в прошлый раз. Если ваши тесты более простые, вы можете уйти с простым списком пар запроса/ответа.

У меня есть флаг в моих модульных тестах, которые указывают, находится ли я в режиме "записи" (то есть, разговаривая с реальным сервером и записывая эту структуру данных на диск), или если я нахожусь в режиме "воспроизведения" (говоря к структуре данных). Когда мне нужно работать с тестом, я "записываю" взаимодействия с сервером, а затем воспроизвожу их.

Я использую малоизвестную функцию SenTestCaseDidStartNotification для отслеживания работы unit test и надлежащего выделения файлов данных.

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

Ответ 2

(Так как никто еще не вошел и дал вам полное пошаговое руководство) Мой скромный совет: немного отступите, вытащите магию асинхронного движения, рассмотрите все как синхронизацию (вызовы api, разбор, упорство) и изолируйте каждый шаг как потребитель/производитель. В конце концов, вы не хотите тестировать NSURLConnection или JSONKit или что-то еще (они должны были быть протестированы, если вы их используете), вы хотите протестировать свой код. Ваш код принимает некоторый ввод и производит вывод, не осознавая того факта, что вход был фактически выходом в фоновом потоке где-то. Вы можете выполнить изолированную проверку всей синхронизации.

Можем ли мы согласиться с тем, что ваши представления не заботятся о том, как были предоставлены данные модели? Если да, хорошо, проверьте свой вид с макетными объектами.

Можем ли мы договориться о том, что вашему парсеру не важно, как были предоставлены данные? Если да, хорошо, проверьте свой парсер с макетными данными.

Сетевой уровень: тот же, что и описанный выше, в конце вы получите NSDictionary заголовков и некоторые NSData или NSString содержимого. Я не думаю, что вы хотите, чтобы вы тестировали NSURLConnection или любую третью стороннюю сеть, которой вы доверяете (asihttp, afnetworking,...?), Поэтому, в конце концов, что нужно протестировать? Вы можете макетировать URL-адреса, запрашивать заголовки и данные POST для каждого используемого вами случая и настраивать тестовые примеры для ожидаемых ответов.

В конце концов, IMHO, все о "нормализации" вне asyc.

Ответ 3

Взгляните на Nocilla

Для получения дополнительной информации, проверьте этот другой ответ на аналогичный вопрос