HTTP 200, а результат неправильный — знакомая ситуация?

Я разрабатываю Checkcraft — приложение для проверки API и логов без написания тестового кода.

Здесь будем разбирать конкретные задачи: сверять JSON с документацией, находить связанные сообщения по traceId, проверять расчёты и повторно запускать сохранённые проверки после изменений.

В примерах будут видны исходные данные, ожидаемый результат и подробный отчёт. Локальный AI помогает подготовить черновики, которые нужно проверить перед добавлением.

Начать можно с бесплатной версии Free (beta) для Windows и Linux:
https://checkcraft.ru/?utm_source=vk&utm_medium=organic_social&utm_campaign=launch_202609&utm_content=welcome

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

Как связать API-запрос с его логами и выбрать нужное сообщение внутри операции? На учебном стенде показываем путь от traceId в ответе до сохранённого Log-прогона и подробного отчёта в Checkcraft.

Скачать Checkcraft бесплатно — по первой ссылке в профиле канала. Поможем с первой проверкой: Telegram и почта для связи доступны на сайте.

В этом примере идентификатор берётся из $.traceId. Источник логов, имя поля связи, модуль и фаза зависят от вашего сервиса. Ошибки на стенде внесены специально.


#Checkcraft​ #тестированиеAPI​ #Kibana

В документации поле называется drink, а в фактическом сообщении — drnik. Разбираем, почему отчёт показывает сразу две ошибки: лишнее поле и отсутствие обязательного.

В Checkcraft такую проверку можно сохранить и повторять после изменений сервиса. Ошибки в учебном примере внесены специально.

Скачать Checkcraft бесплатно — по первой ссылке в профиле канала. Поможем с первой проверкой: Telegram и почта для связи доступны на сайте.

#тестированиеAPI #QA #Checkcraft

Арифметика сходится, а результат не соответствует требованиям. В запросе две порции, но дальше их становится три: получаем 1350 вместо 900 и 1080 после скидки вместо ожидаемых 720.

Показываем, зачем проверять и расчёт, и исходные значения в Checkcraft. Ошибки в учебном примере внесены специально.

Скачать Checkcraft бесплатно — по первой ссылке в профиле канала. Поможем с первой проверкой: Telegram и почта для связи доступны на сайте.

#тестированиеAPI #QA #Checkcraft

В журнале много похожих запросов. Чтобы не проверить чужую запись, возьмите traceId из ответа своей операции, найдите связанные сообщения и выберите нужный этап.

В учебном примере один traceId объединяет шесть сообщений. Эту связь можно использовать в сохранённом Log-прогоне Checkcraft.

Скачать Checkcraft — по ссылке в профиле канала.

Поможем с первой проверкой: контакты Telegram и почты доступны на сайте.
#тестированиеAPI #QA #Checkcraft

Один traceId может объединять несколько сообщений. Для проверки конкретного поля сначала выберите нужный этап операции.

В этом учебном стенде этап задают module и phase. В вашем сервисе поля и значения фильтра могут отличаться. Показываем порядок: идентификатор из ответа → цепочка операции → нужный этап → проверка данных.

Скачать Checkcraft — по ссылке в профиле канала.

Поможем с первой проверкой: контакты Telegram и почты доступны на сайте.
#тестированиеAPI #QA #Checkcraft

Одна опечатка в имени поля — и контракт нарушен. Разбираем, как проверить JSON по документации: найти отсутствующее обязательное поле, лишнее поле и несовпадение ожидаемого значения.

На реальном интерфейсе Checkcraft показываем подготовленные шаги, Log-прогон, подробный отчёт и его сохранение для разбора дефекта. Учебные ошибки внесены специально. Дополнительное поле считается ошибкой только тогда, когда это следует из вашего контракта.

Скачать Checkcraft — по ссылке в профиле канала. Поможем с первой проверкой

00:00 Одна буква меняет контракт
00:16 Берём ожидания из документации
00:32 Наличие, тип и значение
00:45 Ожидаемые данные пользователя
00:59 Шаги проверки и запуск Log-прогона
01:19 Лишнее поле и отсутствие обязательного
01:37 Тип совпал, значение — нет
01:50 Сохраняем отчёт для разбора
02:04 Повторяем сохранённые проверки
#тестированиеAPI #JSON #Checkcraft

HTTP 200 ≠ корректный JSON
HTTP 200 говорит только об одном: сервер успешно обработал запрос. Но это не значит, что данные внутри ответа правильные.
Например, в документации поле называется drink, а в фактическом ответе — drnik. Значение напитка есть, но имя поля ошибочное. Следующий сервис ожидает drink и не найдёт его.
При проверке JSON разделяйте три вещи:
🔹 Наличие — поле существует?
🔹 Тип — значение нужного типа?
🔹 Значение — соответствует требованиям?
Даже правильная строка может находиться не в том поле или содержать неверное значение.
Для теста задайте небольшой контракт: обязательные поля, их типы и допустимые значения. Не копируйте ожидания из заведомо ошибочного ответа — иначе тест просто закрепит дефект.
⚠️ Дополнительные поля — отдельный вопрос. Если контракт разрешает расширение ответа, неизвестное поле само по себе не ошибка. Но в примере выше проблема ещё и в том, что обязательного drink нет.
В Checkcraft такие проверки можно сохранить и запускать повторно, а подробный отчёт показывает данные, на которых основан результат.
С какой ошибкой сталкиваетесь чаще: пропавшее поле, неверный тип или неверное значение?
Я разрабатываю Checkcraft Free (beta) для Windows и Linux: https://checkcraft.ru/
Пример учебный; ошибки внесены специально.

Одна опечатка в JSON — две ошибки в отчёте. Вместо обязательного drinkприходит drnik: лишнее поле появилось, а нужное исчезло. Показываем, как найти такое расхождение при тестировании API в Checkcraft.

Разбираем проверку JSON по документации: обязательные поля, типы данных и ожидаемые значения. Затем запускаем Log-прогон, читаем подробный отчёт и сохраняем проверки для повторного запуска.

Скачать Checkcraft бесплатно — по ссылке в профиле канала.
Нужна помощь с первой проверкой? Поможем разобраться и дойти до первого запуска.

ТАЙМКОДЫ
00:00 Одна опечатка — две ошибки
00:19 Берём ожидания из документации
00:35 Наличие, тип и значение
00:48 Ожидаемые данные пользователя
01:02 Шаги проверки и запуск Log-прогона
01:22 Лишнее поле и отсутствие обязательного
01:40 Тип совпал, значение — нет
01:53 Сохраняем отчёт для разбора
02:07 Повторяем сохранённые проверки

Показан учебный стенд: ошибки внесены специально. Дополнительное поле считается ошибкой, только если это следует из требований вашего контракта.

Формула может быть правильной, а результат — ошибочным

В исходном запросе две порции. Дальше по цепочке сервис получает три. Формула умножает фактическое число порций на норму и считает без арифметической ошибки.

Учебный пример: две порции по 450 дают 900. После скидки 20% ожидается 720. Для трёх порций получаются 1350 и 1080. Обе цепочки арифметически согласованы, но только первая соответствует исходному запросу.

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

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

В учебном стенде Checkcraft ошибка внесена специально. Сохранённые проверки позволяют повторить сценарий после исправления и сравнить результат по тем же требованиям.

В ваших тестах проверяется исходное ожидание или только формула между полями ответа?

Free (beta) для Windows и Linux: https://checkcraft.ru/

Ожидали 720, получили 1080 — при этом формула верна.

Разбираем проверку расчётов API на учебном примере: две порции превращаются в три по пути между запросом и промежуточной записью.

В Checkcraft сравниваем исходный запрос, требования документации и реальные данные в отчёте. Находим, где изменилось portions, почему получилось 1350 вместо 900 и зачем отдельно проверять ожидаемый результат и зависимость между полями.

Скачать Checkcraft бесплатно — по ссылке в профиле канала.
Поможем с первой проверкой

ТАЙМКОДЫ
00:00​ Арифметика и ожидание — отдельно
00:14​ Наш пример — расчёт БЖУ
00:27​ Числа должны пройти всю цепочку
00:40​ Две порции превратились в три
00:55​ 1350 вместо 900
01:06​ Сравним две цепочки по шагам
01:27​ Где помощник экономит действия
01:42​ Повторный прогон без новой генерации

Что проверяете в расчётах: только формулу или ещё исходные значения и ожидаемый итог?

#it​ #программирование​ #айти​ #тестированиеAPI​

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

Разбираем три отдельных ожидания: наличие поля, его тип и значение. В учебном примере сверяем обязательное поле drink с документацией и сохраняем проверку в Checkcraft.

Скачать Checkcraft бесплатно — по ссылке в профиле канала.
Поможем с первой проверкой

Вы отдельно проверяете наличие, тип и значение поля — или обычно хватает одной проверки?

#it​ #программирование​ #айти​ #shorts​ #тестированиеAPI​

В ответе есть drnik, а обязательного drink нет. Одна опечатка в имени поля даёт два расхождения с документацией.

Но любое дополнительное поле JSON не обязательно является ошибкой. Показываем, почему проверка контракта API должна опираться на требования: иначе расширение ответа может привести к ложному падению теста.

Скачать Checkcraft бесплатно — по ссылке в профиле канала.
Поможем с первой проверкой

У вас тест должен падать при любом новом поле в ответе или только при нарушении контракта?

#it​ #программирование​ #айти​ #shorts​ #тестированиеAPI​