CheckcraftКак проверить сохранение данных в БД после запроса API
POST вернул успешный ответ и идентификатор заказа, но запись в базе отсутствует или содержит другое значение. Чтобы проверить сохранение, найдите именно этот заказ и сравните данные с требованием.
Для этого сценария нужны действующая лицензия Pro и сборка с Pro-сценариями. Состав версий описан отдельно.
Определить, что должно сохраниться после POST
В учебном сценарии POST создаёт заказ с total равным 300. Успешный ответ содержит orderId ORD-1042. По договорённости запись должна появиться в таблице orders со статусом READY и суммой 300. Названия таблицы, полей и статус здесь условные. Для своей системы возьмите требования к операции и схему тестовой базы.
{"orderId":"ORD-1042","status":"READY","total":300}Почему успешного ответа недостаточно
Ответ API показывает, что вернул обработчик запроса. Совпадение ответа с отправленным JSON само по себе не подтверждает запись в БД. При асинхронной обработке результат может появиться позже. До проверки согласуйте допустимое время сохранения и источник чтения, чтобы задержку реплики не принять за потерю данных.
Подключиться к тестовой PostgreSQL
В Checkcraft Pro создайте подключение к существующей тестовой базе. Получите адрес и учётную запись с правами SELECT у владельца окружения. Например, локальная учебная база может иметь адрес ниже. Подставьте свои хост, порт и имя базы. «Проверить подключение» подтверждает вход, но права на таблицу нужно проверить отдельно. DBeaver для этой операции не требуется.
jdbc:postgresql://localhost:5432/appНайти запись по идентификатору ответа API
Сохраните SELECT ниже, заменив таблицу и столбцы под свою схему. В поле параметров для отдельной проверки задайте orderId=ORD-1042. В сценарии можно использовать orderId=${orderId}, если предыдущий HTTP-шаг уже сохранил идентификатор ответа в эту переменную. Значение передаётся отдельно от SQL. Выбор последней записи без идентификатора может найти чужой заказ.
SELECT status, total FROM orders WHERE id = :orderIdСравнить данные запроса, ответа и базы
Для учебного примера задайте ожидаемое число строк 1. В поле ожиданий укажите две строки ниже, а total добавьте в числовые столбцы, чтобы 300 и 300.00 считались равными. Ожидание 300 взято из требования к запросу. Если слепо скопировать ошибочные 350 из ответа API, совпадение с БД не подтвердит правильный расчёт.
status=READY
total=300Дождаться асинхронного сохранения
Если по условиям вашей тестовой операции запись должна появиться за 10 секунд, задайте ожидание 10000 мс и интервал 500 мс. Это пример настройки, а не универсальный норматив. Проверка повторяет SELECT до совпадения или истечения времени. Она не повторяет создающий POST. Добавьте сохранённую проверку БД после HTTP-запроса в Pro-сценарии.
Разобрать отсутствие записи и неверные значения
Если строк нет, сначала сверяйте orderId, окружение и время ожидания. Если строка есть, но status или total отличаются, сохраните ожидаемые и фактические значения. Ошибку подключения или прав чтения разбирайте отдельно от отсутствия записи. Для разработчика приложите идентификатор операции, версии сервисов и результат SELECT с разрешёнными к передаче данными.
Выбрать способ повторной сверки
Разовый SELECT можно выполнить в DBeaver, а повторение организовать кодом или с помощью AI. Этот сценарий Checkcraft Pro сохраняет запрос к БД, ожидания и порядок выполнения рядом с API-проверкой. Логи той же операции помогут разобраться, где остановилась обработка. Здесь проверяется одна операция, а не всё хранилище. На своём тестовом примере сопоставьте результат с согласованным требованием.
Начните с примера по ссылкам и сопоставьте результат с требованием своей проверки.