Используете ли вы свои фреймворки или чистый WebDriver с аннотациями

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

Как устроен ваш слой автоматизации и понимаете ли вы, какую проблему решает обёртка над WebDriver. Под «аннотациями» обычно имеют в виду @FindBy из PageFactory и аннотации тестового раннера. Следом спрашивают, как вы запускаете тесты параллельно и как боретесь с нестабильностью.

Как отвечать

Честный ответ почти всегда «и то и другое»: в основе Selenium WebDriver, а поверх него тонкий слой своего кода. Опишите, из чего он состоит:

• управление драйвером: фабрика, которая создаёт браузер по конфигурации (локально или в Selenium Grid), и ThreadLocal<WebDriver> для параллельного запуска. С Selenium 4.6 драйверы скачивает встроенный Selenium Manager, WebDriverManager уже не обязателен;
• Page Object: страницы и компоненты с методами на языке действий пользователя, а не кликов по локаторам. Локаторы через By или @FindBy с PageFactory;
• ожидания: явные через WebDriverWait и ExpectedConditions, без Thread.sleep. Документация Selenium прямо предупреждает против смешивания неявных и явных ожиданий;
• раннер: JUnit 5 (@Test, @BeforeEach, @ParameterizedTest, расширения через @ExtendWith) или TestNG (@DataProvider, группы, @BeforeMethod);
• отчёты и конфигурация: Allure с @Step и скриншотами при падении, параметры окружения из файла или переменных.

Упомяните Selenide: готовую обёртку с автоожиданиями, которая заменяет большую часть самописного кода, и объясните, почему выбрали его или свой слой.

Цифры эффекта (время прогона, доля нестабильных тестов) приводите только свои. Если работали в готовом фреймворке компании, так и скажите и назовите, что дописали сами.

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

Называют «своим фреймворком» BasePage с парой хелперов и Thread.sleep внутри. Первый же вопрос про параллельный запуск и ожидания это вскроет.

Путают уровни: говорят про «аннотации WebDriver», хотя @Test и @BeforeEach принадлежат раннеру, а у самого WebDriver аннотаций нет, кроме @FindBy из пакета поддержки.

Хранят драйвер в статическом поле или забывают ThreadLocal.remove() после quit(). При параллельном запуске тесты управляют чужим браузером, а потоки держат закрытые сессии.