t.me/atinfo_chat Telegram группа по автоматизации тестирования

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

Теги: #<Tag:0x00007f7488422418> #<Tag:0x00007f7488420690> #<Tag:0x00007f74884205c8> #<Tag:0x00007f7488420500> #<Tag:0x00007f74884203c0> #<Tag:0x00007f74884202f8>

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

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

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

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

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

1 Симпатия

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

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

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

src/main/java/ua/com/google/pageobjects
1 Симпатия

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

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

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

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

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

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

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

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