В примитивных тестах - да
Только сами пути выносишь в переменые

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

Это легко пересесть с 5 без PO на уже адекватную реализацию

Язык какой? Питон?

джава

ну вот я и стала разбираться... пока не поздно

Наглядный пример (не скажу что идеальный)
https://youtu.be/RlXihD9NVbM
https://youtu.be/afycPF-9rxM

Алименков доступно рассказывает, во второй части и примеры есть на Джаве

спасибо

ООП дизайн это вообще интересная и сложная тема.  Нет серебряной пули. "Мы использовали ПО, а получилась сложная жуть ничем не лучше, как же так".
Помимо "основного" ПО есть и другие паттерны (Алименков неплохо начинал доклад, есть и другие материалы похожие) .

НО. ООП-дизайн это "разложить методы по коробочкам так чтобы их было удобно доставать". Это не "один размер для всех", и не "один пейджобджект всем".
Бывают ситуации когда на всех страницах меню — и оно делается отдельным объектом. Бывают разбиения сложных менюшек на несколько объектов.
Бывают ПО с флюэнтом и без.
Бывают ситуации когда ПО только усложнит (Солнцев, доклад "10 причин моей ненависти"),
бывают ситуации когда локаторы лучше хранить отдельно и загружать из отдельных файлов (для прогона на похожих-но-разных продуктах), бывают ситуации когда на это можно не заморачиваться и локаторы класть прямо в ПО.

Из-за такого разнообразия возможных ситуаций и "боков" я полагаю неправильным давать только один материал по ПО и ООП. Надо брать несколько материалов и смотреть с разных сторон. ПО это часть процессса, и даже не его краегугольный камень.

Материалы (находятся на Ютубе):

Концептуальные основы ООП на пальцах в контексте QA | Антон Семенченко на QA Z-DAY
https://www.youtube.com/watch?v=Nnlry9rl_us

Десять причин моей ненависти - Андрей Солнцев
https://www.youtube.com/watch?v=pln38fIbYqA

https://www.youtube.com/watch?v=EnooA2kEhY0
Николай Алименков — Паттерны проектирования в автоматизации тестирования

Антипаттерны UI-Автоматизации. Антон Семенченко.
https://www.youtube.com/watch?v=EnooA2kEhY0

10 популярных способов превратить простое в сложное при Автоматизации тестирования
https://www.youtube.com/watch?v=stipcacBp_4

Дмитрий Буздин — Как построить свой фреймворк для автотестов?
https://www.youtube.com/watch?v=vrjN8VTeuOk

Разработка фреймворка для старта UI Автоматизации на примере Selenium. Антон Семенченко
https://www.youtube.com/watch?v=4K-eMpQ4XrY

__________

Материалов много, я понимаю — но несмотря на то что изначальная тема "просто пейджобджект", у неё нет однозначного решения, решение зависит от контекста, где-то пейджобджект может быть вообще не нужен, а где-то он типичная строительная конструкция фреймворка, но надо понимать что типичная строительная и место конструкции.

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

ух ты, вот спасибо

у меня магазин, куча меню и выпадающий список, тоже часть меню, вот и не могу понять как это крутить

Известные мне способы — это

а)  разбивка на пейджелементы (т.е. помимо ПО есть ещё маленькие элемент обджекты).
Варианты — с флюэнтом (в конце метода обджекта обджект) или без. Я знаю что есть компании которые предпочитают только флюэнт, но есть и такие что нет.

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

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

спасибо

Повысьте качество своего приложения с помощью простых QA процессов. Пример BlaBlaLines  и BlaBlaCar.
Мы рассмотрим 3 шага, которые помогут вам достичь и сохранить определенный уровень качества. Для простоты все тесты, упомянутые в этой статье, выполняются вручную. Ни один из них не автоматизирован. https://medium.com/blablacar/improve-your-app-quality-with-simple-qa-processes-cfce0428516e

Ребят, привет. Мне сейчас оч актуальны 2 вопроса) 1. Какие принципиальные преимущества того, когда код с автотестами пишется не в отдельном проекте, а в одном с самим приложением (в src/test/java)? Одно из них  - возможность переиспользовать модели как мне видится. А еще?
Раньше делала отдельным проектом, но вот посмотрела один из докладов Andrei , где вы вскользь говорите, что не считаете это правильным :)

И еще как лучше сделать. Каждый раз перед прогоном тестов предварительно выкачивать из репозитория и стартовать с нуля тестируемое приложение на localhost-е (чтобы каждый раз была чистая база с нужными мне данными). Или не делать этого (обновлять само приложение только при выходе новой версии) и просто очищать БД sql скриптом, например?

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

Если тестировать не только релизы, то очевидно имеет смысл выкачивать каждый раз текущую версию

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