может кто-то подсказать с чем такое связано - для одного теста парсятся шаги, для другого - нет.

потому что судя по синтаксису половина кода написана на питоне..))

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

Привет всем! Полезный чат 👍Меня перенаправили сюда с вопросом по автоматизации back-end'a для веб приложения. Есть такое чувство, что на сопровождение REST-тестов тратиться 80% времени во время разработки. Недостатки java-тестов - это несопостовимые с разработкой API временные затраты на создание в тестах pojo классов для хранения результатов, входных параметров (их количество может достигать порой > 20) и затем однообразных assertions в тестах. Через postman UI - можно гораздо быстрее создать различные API calls (спасибо copy-paste) по сравнению описания их через код. Но, в таком случае, потом возникает проблема их обновления, очень часто разработчики обновляют аттрибуты во время спринтов: меняют имена полей и т.д. И не понятно как обновить postman запросы "пачками". В IDE это сделать проще через рефакторинг или search/replace опции. Все ли сталкиваются с этой проблемой? 🤔

первое что приходит в голову - заюзать генерацию POJO через условный swagger

Во первых выдать дюлей тому, кто там у вас API пишет, что поля меняются каждый спринт

угу, отличный подход)

Я храню не в POJO, а в JsonNode например. Ну или в Map<String, Object>

😄 это постоянно повторяющая история в нашей команде - каждую ретроспективу говорим о важности планирования архетектуры и без толку ((( все равно в итоге что-то нужно переписать/поправить. Я уже не пишу тесты одновременно с разработкой, пока не выпустим стабильный билд

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

Если меняется АПИ, то приходится апдейтить тестовые данные, тут никуда не деться. Самое плохое, что при апдейтах легко внести баг в сами тесты и они могут стать false positive. Поэтому единственное правильное решение - писать API нормально сразу. В любом другом случае тесты все равно придется переписывать

Уделяйте больше времени тестированию спецификации, общению с тем с кем интегрируетесь или клиентами, потом будет меньше времени уходить на поддержку

В случае, когда json входных параметров (body params) API состоит из 11 полей со вложенными объектами. В postman их мне было удобнее скопировать, чем писать set'еры для такого формата. Сейчас храню их в отдельных файлах тест-ресурсов, где удобнее их просматривать и модифицировать. Но опять же, любое изменение структуры - это обновление всех json-ов вручную

API внутренние, их пишут full-stack разработчики, поэтому им не сложно обновить клинт после модификаций

А вам эти тесты вообще профит приносят? сколько времени занимает ручное тестирование, и легче ли стало после автоматизации?)

Согласна 👍

Эм, ну на моем проекте много куда более громоздких сущностей, я описал модели для них в классах и все, сериализация/десериалищация вызовом одного метода.
На написание уходит какое то время, но поддерживать их сильно проще, изменил класс - посмотрел в каких тестах он используется.
А править отдельно каждый тест в постмане, ну хз.
Если вам удобно - дело ваше, на мой взгляд как раз в таких случаях поддерживать код проще.