Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Table of Contents

Tip

Это общедоступный API-метод, который вы можете подергать для ознакомления.

Все методы сделаны для моего курса «Тестирование REST API». Теорию я выкладываю на youtube и в блог, а за практикой заходите!

...

Tip

ТЗ в гуглодоке — копируйте откуда удобно, из гуглодоки или конфлюенса.

Это пример метода из реальной жизни, с кучей условий и бизнес-логики. Именно после тестирования похожего метода в рельной системе я написала блог-пост «В тестировании всегда начинаем с простого!». Будьте внимательны в попытке сократить количество тестов!

Table of Contents


Легенда

Менеджер ищет по пользователям, но его интересуют их задачи в том числе. Или он хочет посмотреть на сотрудников компании “Ромашка”, или сколько в этой компании невыполненных задач.

Заголовки

Заголовок

Описание

Content-Type

Тип данных в запросе: application/json, application/xml, form-data

Accept

Тип данных в ответе: application/json

Входные параметры

Имя параметра

Тип

Обязательный?

Описание

query

string

да

Критерии поиска.

partyType

Выбор:

  • USER
  • COMPANY

нет

Где искать: в юзерах или компаниях

fullSimilarity

boolean

нет

Искать только по полному совпадению (по умолчанию False)

taskStatus

Статус задачи

нет

Искать только тех, у кого есть задачи в таком статусе

include

Набор значений

нет

Дополнительная информация о контрагенте

maxCount

int

нет

Количество результатов, возвращаемых в ответе

Правила формирования раздела <query>

...

Узел <taskStatus> постоянен и содержит следующие части:

Значения параметра //taskStatus

Описание

ALL

Все статусы

ACTUAL

Текущие

COMPLETE

Выполненные

FAIL

Пропущенные

Если мы ищем среди компаний, то проверяются статусы задач по каждому сотруднику.
Если у сотрудника есть задача в таком статусе — вернем компанию и этого сотрудника, остальных сотрудников не вернем. Если у компании 5 сотрудников, но только 2 есть задачи в нужном статусе — вернем компанию и этих двух сотрудников.

...

Узел <include> постоянен и содержит следующие части:

Значения параметра //include

Описание

ALL

Вся информация:

  • пользователь, его компании, его задачи + блок WHY
  • Компания, ее сотрудники, список задач внутри сотрудника + блок WHY

USER

Информация только о найденном пользователе / сотруднике компании

COMPANY

Информация только о компании

TASK

Информация только о задачах пользователя (от самого пользователя указывается email, чтобы различить разных)

WHY

Блок с информацией об атрибутах, в которых нашли совпадение

По умолчанию его можно не указывать в запросе, тогда в ответе вернутся все перечисленные блоки, кроме WHY.
Указать можно несколько значений (массив):

...


В разделе <maxCount> передается количество записей, которые необходимо вернуть в ответе.
Если параметр <maxCount> в запросе не указан, то по умолчанию возвращается 5 записей по пользователем и 5 записей по компаниям с указанием общего количества найденных записей в параметре foundCount. Максимальное количество записей, которое возвращает метод – 30.
Сначала возвращаем юзеров, потом компании. Юзеры в порядке создания (по возрастанию, кто раньше создан, тот и актуальнее), компании по ИД (тоже по возрастанию)


Выходные параметры

Имя параметра

Тип

Описание

foundCount

int

Сколько найдено результатов поиска

results

Пользователь / Компания

Сами результаты

Пользователь

Если найден пользователь, вернуть:
— все поля пользователя. В заголовке (шапке) указывается емейл
— блок компаний, в которых он сотрудник. В заголовке указывается ИД
— блок задач, которые на нем висят. В заголовок выводится ИД и статус (статусы перечислены в разделе Include)
— why-блок (по какой информации нашли компанию)

...