5 простых шагов к созданию сервера для тестирования android REST-запросов

  • Tutorial
Добрый день.

Не так давно возникла необходимость реализации в android приложении общения с API сервера посредством REST-запросов. Реализовать программную часть на android не составило большого труда, в связи с наличием удобной и простой библиотеки Retrofit. Однако, написав пару GET/POST-запросов к существующим открытым API (например, Github и прочие стандартные примеры Retrofit) возникла необходимость начать тестировать логику работы приложения. В данном случае, конечно бы хотелось иметь свой сервер, содержащий свои модели данных и имеющий взаимосвязи между моделями, а также различные уровни доступа к конкретным моделям данных. В данной статье я хотел бы рассказать, как за несколько маленьких шагов создать локальный сервер, добавить необходимые модели, настроить взаимосвязи между ними и обеспечить удаленный доступ к данному серверу.

Сразу хотелось бы уточнить, дабы избежать недопонимания со стороны читающих:
Я, также как и те, для кого предназначена данная статья, являюсь новичком в реализации серверной части, попавшим по воле обстоятельств в ситуацию, в которой я был вынужден сам для себя, максимально быстро поднять api, для тестирования android приложения. Вся информация представленная в статье по крупицам может быть найдена на просторах google и youtube и найти ее и собрать в единое целое не составит особого труда, если знать что искать. Однако это требует времени на принятие решений о технологической реализации, а также на поиск информации для каждого конкретного решения.

1. NodeJS и Loopback


Первое, что нужно сразу уточнить, сервер будет реализован с использованием Node.js-фреймворка Loopback. Для начала установим сам Node.js. Последнюю версию Node.js находится на сайте nodejs.org/en/download, скачиваем ее и устанавливаем.
После этого запускаем командную строку и вводим следующею команду и ждем окончания процесса:

npm install -g loopback-cli


2. Создание приложения


Для создания нового приложения (вашего сервера) для фреймворка Loopback необходимо в командной строке перейти в директорию, в которой будет располагаться ваш сервер, ввести команду lb и ответить на ряд вопросов о приложении, среди которых:

  • имя приложения (в моем случае, test_server)
  • имя каталога, для проекта (оставить пустым, тогда в данной директории создастся папка с названием проекта)
  • версия LoopBack (выбираем текущую версию)
  • вид приложения (формально говоря — шаблон приложения. Выбираем api-server)



После завершения процесса создания приложения, переходим в созданную папку с файлами приложения и пробуем запустить его следующей командой:

node .

Приложение запускается на локальном адресе: localhost:3000/explorer. При этом приложение уже имеет модель User и ряд REST-функций.



Формально говоря, ваш сервер готов и успешно обрабатывает локальные запросы. Проверить доступность и работу сервера можно с помощью приложения Postman или вашего android приложения.

3. Модели и взаимосвязи


Далее необходимо создать модели с данными и взаимосвязи между ними. Рассмотрим, простой пример модели и взаимосвязей: представим, что наше приложение выдает отзывы на фильмы. Вы вводите название фильма и должны получить все отзывы для данного, конкретного фильма. Таким образом в базе данных у Вас, в самом примитивном случае, должно храниться две модели: Movie (имеет поля: name, year) и Review (autor, description). Взаимосвязь у моделей следующая, один фильм может иметь много отзывов.

Таким образом REST-запрос к фильмы будет иметь такую ссылку localhost:3000/api/Movies, а к списку отзывов такую localhost:3000/api/Movies/{id}/Reviews

Создадим две эти модели на сервере:

lb model

Ответим на следующие вопросы о модели:

  • имя модели (например, Movie)
  • источник данных для подключения (выбираем db (memory))
  • базовый класс модели (выбираем PersistedModel)
  • показывать модель с помощью REST API (Да)
  • пользовательская множественная форма (оставляем пустым)
  • общая модель или только сервер (выбираем общую (common))

Теперь модель создана и к ней необходимо добавить поля (для Movie это например name и year):

  • имя свойства(например, name)
  • тип свойства (например, string)
  • является ли обязательным (Да)
  • показывать модель с помощью REST API (Да)
  • значение по умолчанию (оставляем пустым)



После добавления всех свойств, увидев предложение добавить еще одно, просто нажмите «Enter». Также добавляем вторую модель.
Теперь необходимо настроить взаимосвязь между ними. Пишем команду и отвечаем на вопросы:

lb relation

  • выберите модель, для создания взаимосвязи (например, Movie)
  • тип связи (выбираем has many (один ко многим), так как один фильм имеет много отзывов)
  • выбираем модель для взаимосвязи (в нашем случае, Review)
  • имя связи (любое, я напишу reviews)
  • пользовательский ключ (оставляем пустым)
  • промежуточная модель (Нет)
  • разрешить вложение связей (Нет)
  • отключить связь от следующих подключенных объектов (Нет)



Все. Теперь запускаем сервер, той же командой, что и ранее и смотрим localhost:3000/explorer . Видим, что у нас появились наши модели и видно взаимосвязь между ними через id.



4. Удаленный доступ к серверу


Сейчас доступ к серверу ограничен домашней сетью, что не совсем удобно при тестировании с телефона. Попробуем сделать ваш сервер удаленным. Для этого необходимо скачать ngrok, распаковываем в любое удобное место и запускаем. Данная программа предназначена для создания туннеля для вашего localhost:3000, чтобы создать для него удаленный доступ по сгенерированой ссылке. Вводим в ngrok следующие команду:

npm install ngrok -g 
ngrok http 3000




Видим, что программа создала туннель и теперь ваш сервер доступен по представленной ссылке. Имейте введу, что при каждом перезапуске ПК, ссылка в ngrok будет меняться.

Заключение


Выше было представлено, достаточно грубое и сухое описание процесса создания простейшего NodeJs сервера, для тестирования вашего android приложения. Естественно существует масса нюансов связанных даже с теми 4-мя шагами, что я описал.

Помимо того, что я уже описал, всего одной командой можно изменить уровень доступа к api и организовать аутентификацию пользователей. Если кому то интересно — задавайте вопросы в комментариях — отвечу. Сам фреймворк имеет достаточно подробную документацию, в том числе стартовые главы переведены на русский (хоть и для версии 2.0 с другим набором команд)

Да примитивно, да где-то технически глупо, где-то слишком просто, но, для человека, не занимающегося серверными технологиями и нуждающегося в быстром решении для тестирования своих основных задач это решение является максимально простым и быстрым.
Поделиться публикацией
Комментарии 10
    +1
    Node.js-фреймворка Loopback.
    Интересный фреймворк, красиво — надо будет попробовать вместо Express!
      +1

      Зачем такие сложности? Код написанный с применением ретрофита, великолепно покрывается инструментальными тестами с использованием пакета com.squareup.okhttp.mockwebserver и, составленных по документации, ответов сервера.

        0

        Каждому свое, кому-то удобнее так, кому-то

          0

          Мне хотелось попробовпть так, к тосу же я прикрутил авторизацию и хотел прикрутить регистрацию пользвателей по номеру телефона с отправкой смс.

          0
          А почему вместо тунеля, с постоянно меняющимся адресом просто не пробросить порт на роутере? я обычно так делаю. Если конечно IP адрес тоже статичный и «белый».
            0
            У меня динамичный ip. За статичный ip, как правило необходимо доплачивать и ожидать подключения. Мне необходимо было решение здесь и сейчас, на коленках)
            0
            Есть специальный сервис для мокирования серверов apiary (https://apiary.io/). Описать api на нем можно с помощью swagger (https://swagger.io/).
              0
              А не проще написать под это все тесты?
              не логичнее, чтобы серверную часть тестировал — бекенд разработчик, а свою часть уже с помощью, например, моков?
                0
                Верно, но и представленный вариант имеет право на существование. Статья не о том, как тестировать, а о том как быстро накидать сервер для тестирования. Конечно, можно тесты написать, можно использовать открытые API, для проверки работоспособности и т. д.)

                НО, из вашего комментария можно выудить одну очень важную вещь: Писать тесты надо, всегда)
                  0
                  когда у меня была аналогичная проблема — я подменял интерактор, который должен был ходить на сервер и брать какие-то данные, и пользовался уже ей, пока бэкэндщик не закончил свою работу.
                  То что вы сделали имеет место быть, но мне кажется, эффективность падает.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое