А, так это нормально. Посмотрел на иконку Евгения в чате...
О Python я.

А почему JSON из базы надо подгонять? Что будет если его НЕ подгонять?

Обычный вроде процесс: получение JSON, преобразование в данные с которыми работает ЯП, работа с данными, преобразование в JSON, отдача JSON.

Вот, скажем, на сайте одного из сравнительно известных популяризаторов Python (хозяин сайта издал книжку) точно то же описывается.
https://realpython.com/python-json/

Если что-то ну очень простое, вроде проверки-замены, а данные JSON в строковом формате, можно и со строковыми функциями работать.

Но если нет, если надо проверять число элементов, например -- чего б и не работать по стандарту?

Всем халоу ворлд. Такой вопрос.
Прохожусь по курсам селениума, тема пейдж обжекта.
Никак не могу понять, что делает лектор при создании метода на клик по кнопке сайта.
Ниже на скрине выделил 2 метода, первый - его, второй - мой с тем же результатом исполнения.
Зачем так делать? Кто может обьяснить, вообще, что там в методе происходит? Так как раньше с таким не сталкивался( делал либо обычный войд, либо возвращаемый)

в методе clickSignIn на выходе получаешь LoginPage со всеми ее методами/объектами, в этом собственно и смысл page object

"Так как раньше с таким не сталкивался( делал либо обычный войд, либо возвращаемый)"
вообще то если ты приглядишься, ты увидишь в первом методе return new LoginPage)))

это код с урока

В зависимости от того кто и как хочет делать, можно по-разному конструировать объекты. Либо вызывать методы атомарно, либо использовать method chaining. Для того чтобы был возможен chaining метод PO должен возвращать объект страницы на которой оказывается браузер после выполнения действий прописанных в методе.

Источник скринов: https://www.automatetheplanet.com/fluent-page-object-pattern/

Как нравится так и работайте 🤷🏻‍♂️
Хоть как со строкой
Хоть десериализуйте

Не флейма ради, но разных точек зрения освещения для напишу что не все считают что смысл PageObject только в этом. Частично его смысл пересекается с общими смыслами ООП (инкапсуляция та же) -- и это работает без fluent / chaining .  

Доводилось видеть и точку зрения известного автоматизатора что Fluent это антипаттерн и его стоит избегать:
https://www.youtube.com/watch?v=eP1CsV5rt-A

Про то, что смысл ПО в том, чтобы возвращать ПО - можно сильно поспорить, мягко говоря :-)

нет, смысл не в этом, я просто слишком сильно упростил видимо. но скрины Романа наглядно показывают для чего  юзают ПО

и это еще хорошо если объекты из одного по, а если из разных - пришлось бы создавать экземпляры этих разных по

Я вам так сейчас не скажу, потому что тема JSON пока что на уровне ЯННП.
Поэтому и спрашиваю )
Но в целом становится понятнее

Плюсы флуента в ПО в том, что они дают меньше шансов написателю тестов ошибиться, если написатель тестов и написатель ПО разные люди. Тем самым немного увеличивается производительность написателя тестов.

Минусы в том, что они уменьшают производительность написателя ПО. В случае ошибок написателя ПО - сильно уменьшают производительность написателя тестов (он должен ждать фикса ПО или фиксить сам).  Флуент паттерн создаёт в сумме больше кода, чем без него. В некоторых случая код теста с длинной цепочкой плохо читаем.

Под чертой многие соглашаются с тем, что флуент в ПО просто не нужен, так как плюсы минимальны и минусы часто перевешивают.

Второй метод с void - отличный вариант.

Они и с флуентом так же создаются, только не в тесте, а в ПО.