И чтобы из внешнего уровня переопределить локатор, или добавить новый - нужно было добавлять новый метод в класс Page, потом новый метод в класс step, который жёстко же завязан на только что добавленный в Page и ну и в тесте уже использовать степ добавленный. Бред же)

А почему?

И что есть "внешний уровень"?

Это уровень самих тестов

А почему - ну это автор курса так делал, курс от 18 года на юдеми, там он не отвечает уже...

У меня есть подозрение что Вы называете бредом концепции собственно ООП ;) Пейдж обжект или пейдж элемент изолирует-энкапсулирует функционал конкретной страницы или элемент. "Вот этим объектом-элементом мы работаем вот с этим".

Делается это именно для того чтобы объект чему-то соответствовал, там было то что имеет отношение к объекту, и не было того что к нему не имеет.

Соответственно, и степы для работы с этим объектом ссылаются на именно этот объект.

Если есть дублирование элементов, какой-то одинаковой формы на двух разных пейджах, форму могут выделить в один пейдж элемент.

Вам, я так понимаю, эта концепция не нравится.

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

То есть локаторы не передаются в параметрах, они привязаны к методам изнутри

Вы всегда можете написать обёртку на элемент определенного типа, та же кнопка, текст филд, чекбокс и т.д. чтобы ограничить кол-во методов и использовать специально предназначенный объект

Не нарушает.

Если этот дополнительный уровень Вам не нужен, а достаточно myelement.click в степе, без оборачивающего метода вполне можно обходиться.

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

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

Такой подход многие практикуют

Не скажу, что он удобней. Как по мне, лучше иметь пачку своих объектов чем один класс с кучей методов, который отвечает за управление страницей.

Тут речь идет  о том, что PageObject является логическим слепком страницы приложения и не содержит бизнес логики. Его поля инкапсулированы и доступ к ним осуществляется через низкоуровневые публичные методы типа page.clickOkButton(); А тестовая логика лежит в отдельном слое, который вы называете step. Звучит все вполне разумно, чаще всего так и делают.

+ ещё выделение фрагментов

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

Ну смотрите, вот как сделано было, на примере - кликнуть по продукту, кликнуть по корзине, кликнуть по покупке. И для всего этого было написано три метода, которые привязаны к локаторам. С другими локаторами эти методы не работают просто. Это нарушение концепций ооп. Ведь можно сделать один метод, и передавать локатор как параметр

Я пришёл к тому что эта разбивка решает "человеческие проблемы", форму записи команд так чтобы их было удобно находить _и_читать_.

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

Так у вам и предоставляет такой метод фреймворк, который вы используете))

Где же здесь нарушение?