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

Question

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

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

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

Answer 1

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

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

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, чтобы отследить, какой модульный тест запущен, и соответствующим образом изолировать мои файлы данных..

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

Answer 2

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

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

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

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

В конце концов, ИМХО, это все о «нормализации» асинхронного ввода.

Answer 3

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

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