Ну смотрите, зачем просто тестам что-то знать о драйвере? Тесты работают по факту с пейджами (объектами) или хелперами, в этих вещах собственно лежит бизнес логика, реализация. Там-то и юзаем тот самый драйвер…
Тест должен знать только то, что есть страница, которую надо открыть или хелпер, который надо дернуть, затем перейти на другую и из нее что-то проверить.
это самый идеальный вариант, посмотреть как делают другие, там конечно может быть много не оч хороших решений. Но вы уже спрашивали и примерно представляете, что лучше избавляться от драйвера в тестах. Поищите там хорошие примерчики, посмотрите много разных. Посмотрите, как разные люди решают проблему.
рано или поздно придете к Selenide Придет понимание, что писанина собственного селенида забирает кучу времени и дебага, если вы не оч опытный разработчик
Я когда-то подумал, зачем тратить столько времени, если в контексте моих проектов, бизнесу пофигу на чем там у меня тесты написаны, но с селениде получается на много быстрее и проще их писать.
Но на собеседованиях вопросы по селениду вряд ли будут, а вот по WebDriver, будут… Как раз анализ чужого кода хорошо помогает в развитии.
Добрался до ПК, а то с телефона вообще ничего не рассмотреть было.
Вообще, код в последнем примере слегка странный. Драйвер объявлен и в BasePage и в BaseTest. То ли опечатка при спешке, то ли путаница у человека.
Пассажи про [quote=“vmaximv, post:41, topic:13952”]
При плохой архитектуре тоже можно писать код - но не много и не долго.
[/quote]
Для меня мало, что значат. Но вот это уже меняет дело: [quote=“vmaximv, post:41, topic:13952”]
Я бы уже после второго написания строки GoogleHomePage homePage = new GoogleHomePage(getDriver()); выкинул бы этот getDriver() “на мороз”.
[/quote]
Первое отдает маркетинговым буллшитом, а второе - реальный пример проблемы и её исправления. И тут уже сразу понятно почему так делать не комильфо и от какой проблемы избавляемся.