Бывают ли у вас такие длинные конструкции java webdriver ?!

webdriver
, ,
#21

я честно, после просмотра примера Serenty, заюзал степы =)

вот тут http://www.thucydides.info/docs/serenity/#introduction я вижу таки штуки:

@RunWith(SerenityRunner.class)
public class WhenEarningFrequentFlyerStatus {

    @Steps
    TravellerStatusSteps travellerSteps;

    @Test
    public void membersShouldStartWithBronzeStatus() {
        // GIVEN
        travellerSteps.a_traveller_joins_the_frequent_flyer_program();

        // THEN
        travellerSteps.traveller_should_have_a_status_of(Bronze);
    }

    @Test
    public void earnSilverAfter1000Points() {
        // GIVEN
        travellerSteps.a_traveller_joins_the_frequent_flyer_program();

        // WHEN
        travellerSteps.the_traveller_flies(10000);

        // THEN
        travellerSteps.traveller_should_have_a_status_of(Silver);
    }
}

степ, это не какая-то примитивная вещь, а бизнес-операция, логически ценная (типа того)

#22

Ну я обычно указываю тип контрола в качестве префикса, по типу buttonLogOn. Так при вводе, к примеру, bu - intelli sense выведет все button вверху списка, что значительно упрощает поиск нужных элементов, даже не зная точных названий.

Именно так. Компонент должен предоставлять публичные геттеры, описывающие его поведение. При этом, все поля необходимо скрыть от греха подальше.

public SomeForm performSomeAction() {
      scrollerToolbar.createDocument();
      scrollerToolbar.sentToApprove();          
      highlightedDialog.accept();
      return this; // or new SomeForm(), whatever
}

Можно еще и декомпозицию сделать для точечного вызова методов в случае необходимости. Но суть остается прежней: у вас есть кубики - компоненты. Вам их нужно объединить в формы / пейджи. Таким же образом, как вы их видите на экране.

Зависит от детализации самих компонентов. Если это полноценные формы, то их фактически можно трактовать, как пейджи, описывая степы внутри. Если это лишь какой-то специфический набор элементов, то имеет смысл их объединять в формы - что так же будет подобием пейджей. Но тут еще важны связи между действиями. Если вы находитесь в пределах текущей формы, возвращайте ссылку на саму себя. Если вы точно знаете, что действие приведет к отрисовке уже другой формы - возвращаете новый объект. Итого, посредством цепочечного вызова вы как бы будете направлять автоматизатора по нужному маршруту. Так, как задумано вашим приложением.

1 лайк
#23

Спасибо за отклик!

#24

Вот наименования элементов лучше ещё дополнительно подписывать в начале или в конце наименования, какой тип элемента, типа butonSendToApprove, fieldEmail, dropDownCities и так далее - так более наглядно

1 лайк
#25

оо уже описали это)

#26

Сколько погружался в написание читабельного кода, очень редко находил в гите читабельные тесты. Думал ну вот блин почему же никто не подписывает дополнительно что это баттон, почему всё воид, почему нет разделения степов и элементов, думал ну буду писать так как предполагаю - вот и вы мне подтвердили мои мысли) Очень круто, что я не ошибся в своём решении

#27

кстати, а стоит ли всегда поля с элементами делать приватными?

#28

Можно и не делать, работает и так. Но, по “ООП (инкапсуляция)”, надо скрывать эти элементы, чтобы были видны только объекту, в котором они находяться. Да и в редакторе (подсказки) эти паблик элементы вечно мешают, приходится скролить до нужного метода.

@FindBy(xpath = "//*[@id='email']")
private WebElement loginField;

typeIn(this.loginField, name);

Спрашивал у людей с опытом, говорят в личном проекте можно и не ставить, а в серьезном или коммерческом - надо ставить, так правильно, и потом новому разработчику более понятней, что происходит.

Еще вот так тоже работает, без this (loginField) (вроде в пайтоне - это self):

@FindBy(xpath = "//*[@id='email']")
private WebElement loginField;

typeIn(loginField, name);

Но такая запись тоже не совсем корректная. Потому что ты можешь создать такую переменную (с тем же именем), в методе, и обращаться к ней без this.

Поэтому правильней будет делать элементы объекта приватными (private) и использовать с приставкой this.

Если не прав, поправьте плиз…

#29

Ну у меня на личном проекте мало приватных локаторов, разве что только в классах степах для компонента определённого, если пишу для компонента/-ов степы, то локатор для компонента всегда приватный

#30

А для не компонента? Паблики? :slight_smile:

#31

Да в любом случае, потому что у меня разнесены классы компоненты (с локаторами) и классы степы (степы для компонента) в которых уже, сам компонент приватный

#32

я тоже как-то сделал прослойку из степов) она оказалась лишней

#33

Т.е. у тебя локаторы и методы для них в одном классе?

#34

ага, как мне и посоветовал разумно @ArtOfLife

#35

Ну у меня как раз такой случай когда удобнее направлять “автоматизатора”, когда только после определённого действия формы можно получить новую форму и также есть сценарии которые только для одной формы и сценарии которые возвращают другой объект.

Да и плюс классы у меня меньшего размера, а по наименованиям методов, классов и пакетов однозначно становится ясно для чего и что предназначено + javadocs для каждого метода с описанием)

Но не для каждого сайта Component Object подойдёт, только если есть кастомные элементы и особенно когда они могут на старнице в разных блоках находится и иметь различное состояние в зависимости от блока