Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Структура проекта Java + Selenium WebDriver

structure
framework
page-object
infrastructure
webdriver
java
Теги: #<Tag:0x00007f7b6434c920> #<Tag:0x00007f7b6434c7e0> #<Tag:0x00007f7b6434c6a0> #<Tag:0x00007f7b6434c560> #<Tag:0x00007f7b6434c420> #<Tag:0x00007f7b6434c2e0>

(Тест Тестов) #1

Здравствуйте! Имеется проект, написанный на java, на этот проект есть написанные UI тесты по паттерну Page Object. Вопрос, где в структуре проекта должны находиться классы страниц page object, в src/main/java/PageObjectClassesFolder или в src/test/java/PageObjectClassesFolder, и чем это объясняется?


(Sergey Korol) #2

Самописный фреймворк или готовое решение используете?


(Тест Тестов) #3

Без использования фреймворка


(Nikolai) #4

Это обусловлено темплейтом по которому вы работаете.
Оптимально класть в /src/test/pageobject/, либо дополнять этот путь под специфику проэкта.
К примеру здесь лежат в selenium-tests/src/test/java/com/wikia/webdriver/pageobjectsfactory/pageobject/, это обусловлено спецификой проекта.


(Sergey Korol) #5

Тогда в main, просто потому, что pageobject != test. Ну и package path у вас не по конвеншенам сформирован.


(Тест Тестов) #6

Так и сделал, спасибо


(Тест Тестов) #7

Я ориентировался на Standard Directory Layout https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html. А как должен выглядеть?


(Sergey Korol) #8

Я говорил не о ведущей части (специфичной для maven), а о доменной. Обычно вначале указывают перевернутый адрес домена, а затем - набор логически структурированных подкаталогов, среди которых может быть и pageobjects. Например:

src/main/java/ua/com/google/pageobjects

(Тест Тестов) #9

Понял, спасибо большое!


(vmaximv) #10

В таком случае (по идеологии мавена), в test должны находится юнит-тесты для pageobejct’ов :wink:


(Sergey Korol) #11

По такой же логике автоматизаторы не должны использовать unit frameworks для создания functional / acceptance тестов, а failsafe плагину - запрещен вход на территорию tests (он ведь не для unit тестов дизайнился).

Мой же посыл заключался в том, что нечего тесты захламлять “лишними” сущностями. Сейчас это будут pageobjects, завтра туда запихнут DAO + Impl, потом еще кастомных элементов, хэлперов и т.п. Why not? Domain specific ведь. А потом начнутся рассказы о том, что нигде не описаны best practices, я - мол - вижу это так, и попробуй мне доказать обратное.

Понимаю, что it depends on, но я не вижу, по какой причине мы должны выносить pageobjects в тесты, при этом, не размазав границу между тем, что нужно помещать в tests, а что - нет.

Все-таки, автоматизаторы создают приложения для тестирования других приложений. Опираясь на это, pageobject можно отнести к одному из компонентов таких приложений, тем самым, поместив соответствующие сущности в main. Сделаю небольшую оговорочку: речь идет о многомодульном подходе, где framework живет отдельно от пейджей.


(vmaximv) #12

Да все можно организовать так, как тебе удобно, если ты владеешь инструментом :slight_smile:
Но скажите - все ли “гладко” проходит при таком разделении. Когда надо делать compile, а когда testCompile? Как собрать “жирную тестовую” джарку? Как использовать test-scope? Куда ложить ресурсы в main или test? Что делать, если вдруг вам сказали закомитать свои тесты в дев-бранч?


(Sergey Korol) #13

Да, тут соглашусь с тем, что специфика проекта / процессов играет ключевую роль.