Используете ли вы паттерн Page Object

Что проверяют

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

Как отвечать

Суть: на каждую страницу или крупный компонент заводится класс, который прячет локаторы и отдаёт тестам действия на языке предметной области. Тест пишет loginPage.loginAs(user), а не три findElement с кликами. Поменялась вёрстка, правится один класс.

Дальше ваш стек и решения:

• инструменты: Selenium WebDriver или Selenide, JUnit 5 или TestNG, отчёты в Allure. В Selenide ожидания встроены, в чистом Selenium нужны явные WebDriverWait, а не Thread.sleep;
• переходы: метод, ведущий на другую страницу, возвращает её объект, и цепочка читается как сценарий: loginAs(user).openCart().checkout();
• компоненты: шапка, таблица, модальное окно выносятся в отдельные классы и переиспользуются, иначе вырастают классы на тысячу строк;
• локаторы: стабильные атрибуты вроде data-testid, о которых договорились с фронтендом;
• проверки: в тесте, а не в page object. Исключение одно: убедиться, что страница открылась.

Стоит упомянуть, что многие команды уходят от PageFactory с @FindBy к ленивым локаторам By или к Selenide, а на больших проектах иногда берут Screenplay, где вместо страниц описываются роли и действия.

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

Где спотыкаются

Отдают из page object WebElement или голые геттеры локаторов. Тест снова работает с разметкой, и смысл паттерна пропадает.

Кладут assertEquals в методы страницы. Такой класс уже не переиспользовать в негативных сценариях.

Лечат нестабильность через Thread.sleep. Тесты замедляются, а флаки остаются: ждать нужно конкретного условия.