в любой момент можно поменять хттп фреймворк)

Статья звучит почти как гимн "Почему лучше писать на Python".

Со следующего года только начну изучать пайтон, вот тогда уж точно заживу)

Со следующего года только начну изучать пайтон, вот тогда уж точно заживу)

Ну, просто, честно говоря, не первый раз натыкаюсь на статьи о том, как люди пишут килотонны джава кода (не важно даже, на каком языке, джава она везде джава) со всеми этими сериализаторами в объекты, кучей наследования и прочего ада ради того, что бы сматчить в итоге три параметра из респонза в итоговом ассерте. Это выглядит как какой-то космолет.

Распарсил одной строкой, разложил xml в key-value другой, работаешь со словарем. Win.

Не понял о каком варинте говришь ты? Он лучше следующего?: Мне приходит xml завёрнутый в soap, я обрезаю всё что не надо мне, привёл респонс к объекту и работаю с объектом уже

Мне не очень понятно желание завернуть все это в объект.

У тебя есть response с вполне предсказуемой структурой, который сам по себе представляет key:value данные. Сохранил это в key:value структуру и по ключу выдергиваешь нужные значения, вместо размножения классов и их экземпляров.

Да космолёт тот ещё выходит.. Но всё некоторые приведённые объекты мне надо целиком передавать или часть их. Поэтому привожу к объекту и фильтрую его через лямбды а не через json path или xpath

У тебя есть response с вполне предсказуемой структурой, который сам по себе представляет key:value данные. Сохранил это в key:value структуру и по ключу выдергиваешь нужные значения, вместо размножения классов и их экземпляров.

что бы рефакторить без мыслей о суициде

что бы рефакторить без мыслей о суициде

Рефакторить что, собственно?

Рефакторить что, собственно?

если имя поле поменялось, например, еще какая нить дрянь, через ИДЕ говоришь переименовать, и он по всему проекту поменяет, в случае классов

больше видимости, по мне

Подскажите, как правильно передавать данные между шагами кейса при тестировании API?

если имя поле поменялось, например, еще какая нить дрянь, через ИДЕ говоришь переименовать, и он по всему проекту поменяет, в случае классов

Вы не ответили, вы про рефакторинг тестов или рефакторинг апи?

У тебя есть response с вполне предсказуемой структурой, который сам по себе представляет key:value данные. Сохранил это в key:value структуру и по ключу выдергиваешь нужные значения, вместо размножения классов и их экземпляров.

странное определение "вполне предсказуемая структура", я дефакто имею чёткую структуру на основе которой привожу респонс к объекту или работаю с любым элемнетом

Вы не ответили, вы про рефакторинг тестов или рефакторинг апи?

апи

Подскажите, как правильно передавать данные между шагами кейса при тестировании API?

сохраняешь нужные себе данные в переменную и передаёшь переменную другому методу на вход

созранение таких данных лучше делать в теле теста, а не как сохранение состояния - зависит конечно от сценария но всё же

апи

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

сохраняешь нужные себе данные в переменную и передаёшь переменную другому методу на вход

что-то такой вариант показался не совсем бест-практикс рассматривал вариант с записью в файл и вычиткой из файла или это лишний велосипед?

лишний

странное определение "вполне предсказуемая структура", я дефакто имею чёткую структуру на основе которой привожу респонс к объекту или работаю с любым элемнетом

Я просто не понимаю, зачем приводить к объекту то, что само по себе является key:value массивом. Выглядит как абстракция ради абстракции.

Передача данных в сценарии автотеста между действиями через переменные - это норм. А вот сохранение в файл - это уже избыточно..

Я понял, спасибо

Я просто не понимаю, зачем приводить к объекту то, что само по себе является key:value массивом. Выглядит как абстракция ради абстракции.

Для slateless тестов оно может и нормально, словарь отправил - словарь получил. Если же требуется задаваить состояние некой сложной системы, которую тесты крутят - вертят по всякому, и при этом API периодически меняется, поддерживать просто словари становится дорого.

Для slateless тестов оно может и нормально, словарь отправил - словарь получил. Если же требуется задаваить состояние некой сложной системы, которую тесты крутят - вертят по всякому, и при этом API периодически меняется, поддерживать просто словари становится дорого.

Собирать словарь не дороже, чем собирать объект, только не требует дополнительно обновлять модель при любой изменении.

Про парсить уж вообще молчу.

@azshoo может в пайтоне это легко работать чисто с ключ значение, но в джава придётся работать в любом случае с помощью xpath или json path - т.е. как со строками Приведение к объекту позволяет же сгенерировать документ с которым я могу сранивть ответ от сервака - просто создав экземпляр с данными. А храня такие объекты на котлине в виде дата классов - даёт мне лёгкую читабельность того что есть в объекте

Про парсить уж вообще молчу.

gson?

gson?

это опечатка или я чего-то не знаю?

gson?

Gson это здорово. Рождает потрясающие полотна кода при ненулевом уровне вложенности.

это опечатка или я чего-то не знаю?

Это библиотека.

@azshoo может в пайтоне это легко работать чисто с ключ значение, но в джава придётся работать в любом случае с помощью xpath или json path - т.е. как со строками Приведение к объекту позволяет же сгенерировать документ с которым я могу сранивть ответ от сервака - просто создав экземпляр с данными. А храня такие объекты на котлине в виде дата классов - даёт мне лёгкую читабельность того что есть в объекте

Но зачем вам в рамках теста сравнивать объект с объектом? Или у вас all-to-all ассерты?

Gson это здорово. Рождает потрясающие полотна кода при ненулевом уровне вложенности.

ну смотря какой АПИ

ну смотря какой АПИ

Ну, если в API есть только JSONы нулевого уровня вложенности, то их сериализация в объекты выглядит ещё более бессмысленной. Так можно, хотя бы, сослаться на то, что оперировать структурами данных внутри объекта (upd.) красивее, чем в словаре.

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

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

И это классический Java-way, херачить излишние абстракции и сущности, которые приходится потом расширять и поддерживать, вместо того, что бы сравнивать value с value.

О чем, собственно, и речь.

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

Ну, если в API есть только JSONы нулевого уровня вложенности, то их сериализация в объекты выглядит ещё более бессмысленной. Так можно, хотя бы, сослаться на то, что оперировать структурами данных внутри объекта (upd.) красивее, чем в словаре.

у нас например такой укуренный протокол: { "status": true, "data": { "order": { "id":1, "name": "Kotikov" } } }

И это классический Java-way, херачить излишние абстракции и сущности, которые приходится потом расширять и поддерживать, вместо того, что бы сравнивать value с value.

Да не хотим мы париться с json или xml path... я хочу в коде иметь уже готовый объект в котором я точно не ошибусь при извелениии данных

Вы и так и так их парсите, просто помимо парсинга занимаетесь ещё и их сериализацией.

десериализацией и сериализацией

В чем разница между работой с объектом и работой со словарем, и где во втором случае кроется возможность ошибки - я хз. Может я чего-то не понимают.

Собирать словарь не дороже, чем собирать объект, только не требует дополнительно обновлять модель при любой изменении.

А собирать словать из трех словарей? А хотя бы с минимальной валидацией? А если важен порядок "собирания"? Очень сильно зависит от задач короче.

А собирать словать из трех словарей? А хотя бы с минимальной валидацией? А если важен порядок "собирания"? Очень сильно зависит от задач короче.

Что вы понимаете под минимальной валидацией? Вы тестовые данные, которые собираете для ассерта в тесте, собираетесь дополнительно валидировать? Если да, то зачем (и что важнее, почему вы это делаете в рамках теста)?

Тестирование API это взять статичные данные, отправить на сервер, получить ответ, сравнить его по ключевым параметрам с ожидаемым (статичным, опять же) результатом.

> А если важен порядок "собирания"? что за зверь такой?

Я могу понять необходимость накручивания объектов и классов когда внутри объекта могут лежать ссылки на другие объекты, и такая вложенность достигает бесконечности. Но в случае с API запросами это всё, в итоге, всё равно приводится к строке с key:value. Следовательно складывание это всё в объекты и раскладывание обратно выглядит как переливание из пустого в порожнее ради сохранения ООП.

Я могу понять необходимость накручивания объектов и классов когда внутри объекта могут лежать ссылки на другие объекты, и такая вложенность достигает бесконечности. Но в случае с API запросами это всё, в итоге, всё равно приводится к строке с key:value. Следовательно складывание это всё в объекты и раскладывание обратно выглядит как переливание из пустого в порожнее ради сохранения ООП.

вот кстати как раз, у нас вложенность достигается до 3-4 с морей инфы и классы реюзаются в других местах

Да кстати, вопрос. Есть сценарные апи тесты которые написаны на "java", их надо запускать на проде некоторое время. Их около 10 штук. Так вот, если их запускать через крон из под только одного каталога, не будет ли проблем? Бо я думаю будут проблемы с файловой системой, типа рид врайт еррор. Выходит что нужно копипастить проект для запуска кроном разных тестов?

вот кстати как раз, у нас вложенность достигается до 3-4 с морей инфы и классы реюзаются в других местах

слабенько)) у меня есть с вложенностью 10

слабенько)) у меня есть с вложенностью 10

ну нахер.jpeg ?)

Да кстати, вопрос. Есть сценарные апи тесты которые написаны на "java", их надо запускать на проде некоторое время. Их около 10 штук. Так вот, если их запускать через крон из под только одного каталога, не будет ли проблем? Бо я думаю будут проблемы с файловой системой, типа рид врайт еррор. Выходит что нужно копипастить проект для запуска кроном разных тестов?

почему внезапно вылезит read write error?

ну к примеру если в один момент времени будет одновременное обращение к одному классу

из разных тестов

слабенько)) у меня есть с вложенностью 10

И в этот момент, кажется, пора вынести всю эту логику из тестов нахрен в отдельный test data factory.

Но это, конечно, моё сугубо личное имхо.

ну к примеру если в один момент времени будет одновременное обращение к одному классу

дык, не должно быть такого, это дичь какая то, или я что то не вкуриваю

И в этот момент, кажется, пора вынести всю эту логику из тестов нахрен в отдельный test data factory.

а причём тут логика до ответа с вложенностью большой элементов

ну к примеру тест запускает из одних исходников с помощью gradle someTask

Тестирование API это взять статичные данные, отправить на сервер, получить ответ, сравнить его по ключевым параметрам с ожидаемым (статичным, опять же) результатом.

Это в идеальном случае, а если на бэкэнде висит какая-нибудь херня с машин лернингом, которая на поток входящих данных когда-нибудь как-нибудь среагирует? Когда параллельно идут данные для обучения, параллельно - дергается API для сбора статистики. В статике его бесполезно дергать, тут нужно держать целое состояние теста, собирать статистику и т д.

а причём тут логика до ответа с вложенностью большой элементов

Я говорил, скорее, про запрос и тестовые данные для ассерта а не ответ. В респонзе у тебя строка всегда и везде, там нет вложенности обьектов.

такие проблемы были когда отчёты junit записывались в хмл, я отключил их и от греха подальше тогда для двух тестов скопипастил просто проект и запускал из под другой дирректории

такие проблемы были когда отчёты junit записывались в хмл, я отключил их и от греха подальше тогда для двух тестов скопипастил просто проект и запускал из под другой дирректории

ну я делаю так, на каждый запуск пачки тестов, указываю Output директорию по времени (часы_минута_день_месяц_год)

Это в идеальном случае, а если на бэкэнде висит какая-нибудь херня с машин лернингом, которая на поток входящих данных когда-нибудь как-нибудь среагирует? Когда параллельно идут данные для обучения, параллельно - дергается API для сбора статистики. В статике его бесполезно дергать, тут нужно держать целое состояние теста, собирать статистику и т д.

Тут надо разделять то, что вы тестируете и тестировать API отдельно от Машинлернинга, получать респонз по коллбэку и проверять валидность API-контракта.

ну я делаю так, на каждый запуск пачки тестов, указываю Output директорию по времени (часы_минута_день_месяц_год)

оо вот это вот спасибо!

Я говорил, скорее, про запрос и тестовые данные для ассерта а не ответ. В респонзе у тебя строка всегда и везде, там нет вложенности обьектов.

и эту строку я привожу к объекту с вложенными собратьями

и эту строку я привожу к объекту с вложенными собратьями

Да, это я уже понял.

Тут надо разделять то, что вы тестируете и тестировать API отдельно от Машинлернинга, получать респонз по коллбэку и проверять валидность API-контракта.

Ага, чтобы оно в тестах по отдельности работало, а все вместе в проде поехало :)

Не, в целом я даже согласен с таким подходом, если речь идет о сайтиках и тривиальном API

Ага, чтобы оно в тестах по отдельности работало, а все вместе в проде поехало :)

Ну, вы можете почитать про уровни тестирования и вот это всё.

Это работает везде, хоть на сайтиках, хоть на самолетах.

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

привет, кто может подсказать в чем причина: переехал на мак - тесты на селениде перестали работать, браузер и страницы открываются, но тупо не видил локаторов - не найдены на странице

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

Я не говорил, что строка не имеет вложенности. Я говорил про вложенность объектов, т.е. когда в коде идет операция над объектами (напр. настройки вебдрайвера кастомятся и дальше этот драйвер, как ссылка на entity в памяти, передается дальше). Но это ситуация не про API, потому что API предполагает что на входе и на выходе у тебя всегда будет текстовый формат данных. Не важно, какой вложенности. Зачем преобразовывать текстовую дату в кастомный объект, вместо более примитивных (и уже реализованных) типов - в этом и был вопрос.

всем хеллоу, есть те кто под espresso тесты гоняет? отчеты в чем сделаны потом? после прогона

всем хеллоу, есть те кто под espresso тесты гоняет? отчеты в чем сделаны потом? после прогона

Allure report ?

allure2 уже есть

allure2 уже есть

хм, спасибки)

лан спс, гляну)

Я не говорил, что строка не имеет вложенности. Я говорил про вложенность объектов, т.е. когда в коде идет операция над объектами (напр. настройки вебдрайвера кастомятся и дальше этот драйвер, как ссылка на entity в памяти, передается дальше). Но это ситуация не про API, потому что API предполагает что на входе и на выходе у тебя всегда будет текстовый формат данных. Не важно, какой вложенности. Зачем преобразовывать текстовую дату в кастомный объект, вместо более примитивных (и уже реализованных) типов - в этом и был вопрос.

Ещё вариант - пришедшие данные нужно пересчитать, посчитать хеши, сделать обмен ключами, дослать то чего нехватает, придумать-еще-плясок с бубном, при которых один ответ в API не может считаться полноценной транзакцией. Всё через словари костылять?

Ещё вариант - пришедшие данные нужно пересчитать, посчитать хеши, сделать обмен ключами, дослать то чего нехватает, придумать-еще-плясок с бубном, при которых один ответ в API не может считаться полноценной транзакцией. Всё через словари костылять?

Нет, тут, кажется, есть более важные архитектурные проблемы в тестах. :)

Но в целом да, собирать запросы и валидировать респонзы проще словарями, чем объектами.

Всё остальное - выносить из логики теста и использовать те структуры данных, которые подходят для конкретного случая.

Но в целом да, собирать запросы и валидировать респонзы проще словарями, чем объектами.

А в мастштабе n тысяч кейсов оно читаемо-поддерживаемо остается?

учитывая, что можно легко накосячить с именем ключа в этом злочастном словаре...

А в чем, собственно, разница масштабируемости между словарем и объектом, если вы правильно декомпозируете тесты и используете в них только те значения, которые важны для ассерта, вынося всю лишнюю логику во вне?

учитывая, что можно легко накосячить с именем ключа в этом злочастном словаре...

Ну, да, бороться с невнимательностью посредствам структур данных в тестах - хорошая практика. (на самом деле нет)

неужели так сложно написать пару классов, камон

или вообще сгенерировать по схеме

Писать код вообще не шибко сложно. Можно хоть три десятка, если вечер продуктивный. Ключевой вопрос: "Зачем?"

Мы же не пишем, по каким-то причинам, кастомные классы для цифр, строк и всего прочего. Потому что уже реализовано, есть из коробки. Зачем генерировать кастомные классы для данных, которые всегда приходят и уходят только в key:value - я не очень понимаю.

для переиспользования в других проектах, как вариант

и ты так говоришь, будто на питоне можно писать в 2 раза больше тестов за день

Нет, я говорю, что можно писать те же тесты, используя вдвое меньше излишних абстракций, втрое меньше кода и не фонтанируя потом историями о том "Как я победил сериализацию в gson всего за три дня и 800 строк кода".

Нет, я говорю, что можно писать те же тесты, используя вдвое меньше излишних абстракций, втрое меньше кода и не фонтанируя потом историями о том "Как я победил сериализацию в gson всего за три дня и 800 строк кода".

хрена, у нас такого не было О_о