JSONPlaceholder: чему он учит, а чему научить не может

Что даёт JSONPlaceholder

• Предсказуемые ресурсы. Посты, комментарии, пользователи, задачи и альбомы — со стабильными идентификаторами и единообразной структурой.

• Все HTTP-методы. GET, POST, PUT, PATCH и DELETE — все отвечают осмысленно.

• Вложенные связи. Комментарии принадлежат постам, посты — пользователям. Структуры достаточно, чтобы на ней тренироваться.

Случайный урок

Запись в JSONPlaceholder имитируется. Вы отправляете POST, получаете 201 с идентификатором — и ничего не сохранилось. Запросите объект обратно, и его там не окажется.

Большинство считает это ограничением. На самом деле это самое полезное, что есть в сервисе, потому что оно разделяет две вещи, которые новички постоянно путают: запрос выполнен успешно и изменение действительно произошло. Набор тестов, который проверяет только коды статусов, будет уверенно и бесконечно проходить здесь любой тест на запись.

Если ваша проверка переживает фиктивную запись в JSONPlaceholder, значит, проверка слабая. Перепишите её так, чтобы она убеждалась: объект после запроса действительно существует, — и перенесите эту привычку на свой настоящий API, где та же слабость незаметна.

Что здесь отрабатывать и в каком порядке

Чему он научить не может

Всему, что связано с состоянием, — то есть всему, из-за чего тестирование настоящих API сложное. Сессии и их истечение, значения, взятые из одного ответа и использованные в следующем, вызовы, которые должны идти в определённом порядке, и очистка после прогона. Ничего этого в JSONPlaceholder нет, потому что данные не сохраняются.

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

Первый час, который пригодится дальше

Если хотите, чтобы тренировка чего-то стоила на вашем собственном API, выполните эти четыре шага по порядку, а не исследуйте наугад.

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

Последний шаг — и есть смысл всего упражнения. Запись отчиталась об успехе, идентификатор вернулся, а данные не сохранились. Все привычки, которые стоит перенести на настоящий API, сводятся к тому, чтобы понять, почему ваш тест всё равно прошёл, и переписать его так, чтобы он не проходил.

Переход на настоящий сервис

Эти четыре вещи специализированный слой берёт на себя как Auto-Authentication, Dynamic Variables, Dependency Chains и Auto-Cleanup. Механика описана в документации по тестированию API.

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

Что меняется, когда вы направляете его на настоящий API

Всё, чему JSONPlaceholder научить не может, берёт на себя TestSprite. Auto-Authentication — для сессий, которые истекают посреди прогона. Dynamic Variables — для идентификатора, который возвращает вызов создания. Dependency Chains — для вызовов, которые невозможны, пока не произошло что-то другое. Auto-Cleanup — для записей, остающихся после каждого прогона.

Начало то же, что и в упражнении выше: направьте проект на свой базовый URL, дайте API Discovery перечислить то, что есть, и прочитайте сгенерированный план, прежде чем что-либо запускать. Разница в том, что теперь план охватывает авторизацию и граничные случаи на сервисе, где запись действительно сохраняется.

Вы получаете то, к чему вела вся тренировка: проверки, которые выдерживают столкновение с состоянием и выполняются при каждом изменении, а не тогда, когда вы про них вспомните.