@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);
}
}
степ, это не какая-то примитивная вещь, а бизнес-операция, логически ценная (типа того)
Ну я обычно указываю тип контрола в качестве префикса, по типу buttonLogOn. Так при вводе, к примеру, bu - intelli sense выведет все button вверху списка, что значительно упрощает поиск нужных элементов, даже не зная точных названий.
Именно так. Компонент должен предоставлять публичные геттеры, описывающие его поведение. При этом, все поля необходимо скрыть от греха подальше.
public SomeForm performSomeAction() {
scrollerToolbar.createDocument();
scrollerToolbar.sentToApprove();
highlightedDialog.accept();
return this; // or new SomeForm(), whatever
}
Можно еще и декомпозицию сделать для точечного вызова методов в случае необходимости. Но суть остается прежней: у вас есть кубики - компоненты. Вам их нужно объединить в формы / пейджи. Таким же образом, как вы их видите на экране.
Зависит от детализации самих компонентов. Если это полноценные формы, то их фактически можно трактовать, как пейджи, описывая степы внутри. Если это лишь какой-то специфический набор элементов, то имеет смысл их объединять в формы - что так же будет подобием пейджей. Но тут еще важны связи между действиями. Если вы находитесь в пределах текущей формы, возвращайте ссылку на саму себя. Если вы точно знаете, что действие приведет к отрисовке уже другой формы - возвращаете новый объект. Итого, посредством цепочечного вызова вы как бы будете направлять автоматизатора по нужному маршруту. Так, как задумано вашим приложением.
Вот наименования элементов лучше ещё дополнительно подписывать в начале или в конце наименования, какой тип элемента, типа butonSendToApprove, fieldEmail, dropDownCities и так далее - так более наглядно
Сколько погружался в написание читабельного кода, очень редко находил в гите читабельные тесты. Думал ну вот блин почему же никто не подписывает дополнительно что это баттон, почему всё воид, почему нет разделения степов и элементов, думал ну буду писать так как предполагаю - вот и вы мне подтвердили мои мысли) Очень круто, что я не ошибся в своём решении
Можно и не делать, работает и так. Но, по “ООП (инкапсуляция)”, надо скрывать эти элементы, чтобы были видны только объекту, в котором они находяться. Да и в редакторе (подсказки) эти паблик элементы вечно мешают, приходится скролить до нужного метода.
Спрашивал у людей с опытом, говорят в личном проекте можно и не ставить, а в серьезном или коммерческом - надо ставить, так правильно, и потом новому разработчику более понятней, что происходит.
Еще вот так тоже работает, без this (loginField) (вроде в пайтоне - это self):
Ну у меня на личном проекте мало приватных локаторов, разве что только в классах степах для компонента определённого, если пишу для компонента/-ов степы, то локатор для компонента всегда приватный
Да в любом случае, потому что у меня разнесены классы компоненты (с локаторами) и классы степы (степы для компонента) в которых уже, сам компонент приватный
Ну у меня как раз такой случай когда удобнее направлять “автоматизатора”, когда только после определённого действия формы можно получить новую форму и также есть сценарии которые только для одной формы и сценарии которые возвращают другой объект.
Да и плюс классы у меня меньшего размера, а по наименованиям методов, классов и пакетов однозначно становится ясно для чего и что предназначено + javadocs для каждого метода с описанием)
Но не для каждого сайта Component Object подойдёт, только если есть кастомные элементы и особенно когда они могут на старнице в разных блоках находится и иметь различное состояние в зависимости от блока