Формула может быть правильной, а результат — ошибочным В исходном запросе две порции. Дальше по цепочке сервис получает три. Формула умножает фактическое число порций на норму и считает без арифметической ошибки. Учебный пример: две порции по 450 дают 900. После скидки 20% ожидается 720. Для трёх порций получаются 1350 и 1080. Обе цепочки арифметически согласованы, но только первая соответствует исходному запросу. Поэтому полезны две независимые проверки. Первая сравнивает итог с ожидаемым значением по требованиям. Вторая проверяет арифметическую зависимость фактических полей. Одна не заменяет другую. Промежуточные сообщения помогают найти место, где изменилось количество порций. Это полезнее, чем знать только о неправильном финальном числе. В учебном стенде Checkcraft ошибка внесена специально. Сохранённые проверки позволяют повторить сценарий после исправления и сравнить результат по тем же требованиям. В ваших тестах проверяется исходное ожидание или только формула между полями ответа? Free (beta) для Windows и Linux: checkcraft.ru
Checkcraft — тестирование API без кода
HTTP 200 ≠ корректный JSON HTTP 200 говорит только об одном: сервер успешно обработал запрос. Но это не значит, что данные внутри ответа правильные. Например, в документации поле называется drink, а в фактическом ответе — drnik. Значение напитка есть, но имя поля ошибочное. Следующий сервис ожидает drink и не найдёт его. При проверке JSON разделяйте три вещи: 🔹 Наличие — поле существует? 🔹 Тип — значение нужного типа? 🔹 Значение — соответствует требованиям? Даже правильная строка может находиться не в том поле или содержать неверное значение. Для теста задайте небольшой контракт: обязательные поля, их типы и допустимые значения. Не копируйте ожидания из заведомо ошибочного ответа — иначе тест просто закрепит дефект. ⚠️ Дополнительные поля — отдельный вопрос. Если контракт разрешает расширение ответа, неизвестное поле само по себе не ошибка. Но в примере выше проблема ещё и в том, что обязательного drink нет. В Checkcraft такие проверки можно сохранить и запускать повторно, а подробный отчёт показывает данные, на которых основан результат. С какой ошибкой сталкиваетесь чаще: пропавшее поле, неверный тип или неверное значение? Я разрабатываю Checkcraft Free (beta) для Windows и Linux: checkcraft.ru Пример учебный; ошибки внесены специально.
Как найти нужные логи среди похожих запросов? В журнале может быть несколько запросов к одному адресу. Тело похожее, а время отличается на доли секунды. Искать только по времени рискованно: можно открыть другую операцию. Если система передаёт traceId, используйте его как связь: получите идентификатор из ответа своего запроса и найдите по нему сообщения в источнике логов. Затем выберите нужный этап по module и phase. В учебном стенде Checkcraft одна операция оставляет шесть сообщений. traceId объединяет их, а module и phase помогают проверить конкретное сообщение. Для следующего запуска нужен новый traceId. Старое значение из Kibana не должно использоваться как постоянная подстановка. Если traceId не передаётся между сервисами или используется для разных операций, фильтр сам проблему не исправит — сначала нужно проверить трассировку. Как вы сейчас связываете запрос с его промежуточными сообщениями? Мы разрабатываем Checkcraft. Free (beta) для Windows и Linux: checkcraft.ru
HTTP 200, а результат неправильный — знакомая ситуация? Разработан Checkcraft — приложение для проверки API и логов без написания тестового кода. Здесь будем разбирать конкретные задачи: сверять JSON с документацией, находить связанные сообщения по traceId, проверять расчёты и повторно запускать сохранённые проверки после изменений. В примерах будут видны исходные данные, ожидаемый результат и подробный отчёт. Локальный AI помогает подготовить черновики, которые нужно проверить перед добавлением. Начать можно с бесплатной версии Free (beta) для Windows и Linux: checkcraft.ru/...ome Какую проверку вам чаще всего приходится повторять вручную? Напишите пример без паролей, токенов и личных данных.
