Тестирование URL-адресов HATEOAS

Я разрабатываю сервис с RESTful API. API основан на JSON и использует HAL для ссылок HATEOAS между ресурсами.

Реализация не имеет значения для вопроса, но я использую Java и Spring MVC.

Некоторые примеры запросов:

GET /api/projects

{
  "_links" : {
    "self" : {
      "href" : "example.org/api/projects"
    },
    "projects" : [ {
      "href" : "example.org/api/projects/1234",
      "title" : "The Project Name"
    }, {
      "href" : "example.org/api/projects/1235",
      "title" : "The Second Project"
    } ]
  },
  "totalProjects" : 2,
}

GET /api/projects/1234

{
  "_links" : {
    "self" : {
      "href" : "example.org/api/projects/1234"
    },
    "tasks" : [ {
      "href" : "example.org/api/projects/1234/tasks/543",
      "title" : "First Task"
    }, {
      "href" : "example.org/api/projects/1234/tasks/544",
      "title" : "Second Task"
    } ]
  },
  "id" : 1234,
  "name" : "The Project Name",
  "progress" : 60,
  "status" : "ontime",
  "targetDate" : "2014-06-01",
}

Теперь, как мне протестировать GET-запросы к одному проекту? У меня есть два варианта, и я не уверен, какой из них лучше:

  1. Тестирование /api/projects/{projectId} в тестах, замена {projectId} идентификатором проекта, который ожидает/возвращает уровень фиктивного сервиса.

  2. Сначала запрашивается /api/projects/, а затем проверяются ссылки, возвращаемые в ответе. Таким образом, в тесте не будет жестко закодировано /api/projects/{projectId}.

Первый вариант делает тесты намного проще, но он в основном жестко кодирует URL-адреса, чего HATEOAS изначально хотел избежать. Тесты также должны быть изменены, если я когда-либо изменю структуру URL по той или иной причине.

Второй вариант более "правильный" в смысле HATEOAS, но тесты будут гораздо более запутанными; Мне нужно обойти все родительские ресурсы, чтобы протестировать дочерний ресурс. Например, чтобы протестировать запросы GET к задаче, мне нужно запросить /api/projects/, получить ссылку на /api/projects/1234, запросить это и получить ссылку на /api/projects/2345/tasks/543 и, наконец, проверить это! Мне также нужно будет больше имитировать в каждом тесте, если я буду тестировать таким образом.

Преимущество второго варианта в том, что я могу свободно менять URL-адреса, не меняя тесты.


person imgx64    schedule 19.03.2014    source источник


Ответы (3)


Если вашей целью является тестирование Hypermedia API, то ваши инструменты тестирования должны понимать, как обрабатывать гипермедиа, содержащиеся в ресурсе, и действовать с ними.

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

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

person PeterB    schedule 24.03.2014

Я не знаю о HATEOAS. Но что я могу сказать.

Вы можете попробовать swat — DSL на основе Perl, Curl для автоматизации тестирования веб-служб и остальных сервисов. Swat был разработан, чтобы упростить манипулирование URL-адресами, о чем вы, вероятно, здесь говорите. Краткая справка о том, как это можно сделать с помощью SWAT (прямой путь, но есть более элегантные решения):

$ mkdir -p api/project/project_id
$ echo '200 OK' > api/project/project_id/get.txt

$ nano  api/project/project_id/hook.pm

   modify_resource(sub{
     my $r = shift; # this is original rout api/project/project_id/
     my $pid = $ENV{project_id};
     $r=~s{/project_id}{$pid} # dynamically setup route to api/project/{project_id}
     return $r;
   }); 

$ project_id=12345 swat  http://your-rest-api # run swat test suite!

Более сложные примеры можно найти в документации.

(*) Раскрытие информации – я являюсь автором инструмента.

person Alexey Melezhik    schedule 27.01.2016

Если вы используете Spring HATEOAS, вы можете использовать ControllerLinkBuilder (http://docs.spring.io/autorepo/docs/spring-hateoas/0.19.0.RELEASE/api/org/springframework/hateoas/mvc/ControllerLinkBuilder.html ) для создания ссылок в ваших тестах, как описано в http://docs.spring.io/spring-hateoas/docs/0.19.0.RELEASE/reference/html/#fundamentals.obtaining-links. В ControllerLinkBuilder нет жестко заданных URL-адресов.

ControllerLinkBuilderUnitTest.java (https://github.com/spring-projects/spring-hateoas/blob/4e1e5ed934953aabcf5490d96d7ac43c88bc1d60/src/test/java/org/springframework/hateoas/mvc/ControllerLinkBuilderUnitTest.java) показывает, как использовать ControllerLinkBuilder в тестах.

person Denis    schedule 02.02.2016