Когда прекратить определение FindBy в объекте и перенести их в тест

Итак, у меня есть интересная головоломка, мне было любопытно получить отзывы от других архитекторов фреймворка Webdriver. В настоящее время я следую довольно стандартной модели выполнения:

  • базовый объект
  • pageobject (расширяет базовый объект)
  • Junit testobject (ссылается на один или несколько объектов страницы)

В моих объектах страницы я решил определить сопоставления пользовательского интерфейса findBy как переменные и, в свою очередь, ссылаться на них в различных методах, которые я пишу для этого объекта страницы. Я считаю, что это работает очень хорошо. Тем не менее, один вопрос, над которым я размышляю, заключается в том, как обрабатывать дизайн методов для страниц (и их соответствующих объектов страницы), когда существует потенциально 50 отдельных гиперссылок.

Моя склонность и дизайн до сих пор состояли в том, чтобы создать методы (я думаю о них как о службах) для каждой ссылки на большинстве объектов страницы, которые я создал, чтобы @Test я мог просто вызвать метод, который я хочу, и покончить с ним. Это устраняет возможность проведения тестов... стандартная практика, которую я знаю. Но сейчас я пытаюсь решить... имеет ли смысл создавать 50 методов, по одному для каждой ссылки для объекта страницы, или я иду против своего желания и передаю текст ссылки из самого теста, вводя его в один метод, который создает findBy, используя переданный параметр.

С одной стороны, внутри pageobject намного меньше кода, но с другой стороны, тесты становятся более хрупкими. Эти ссылки могут быть ссылками в сотнях тестов.

Вот краткий пример моей модели:

classname extends baseobject{

   By someLocator = By.linkText("some text");
   By someOtherLocator = By.linkText("some other text");
   By andAnotherLocator = By.id("someid");

   public void someLinkMethod(){
    driver.findElement(someLocator).click();
   }

   public void someOtherLinkMethod(){
    driver.findElement(someOtherLocator).click();
   }

   public void someidMethod(){
    driver.findElement(andAnotherLocator).click();
   }

}

Таким образом, мы подошли к концу вопроса. Эта модель отлично подходит для тестового дизайна. Мои сервисы (методы) изолированы и легко обслуживаются. Но что бы я сделал, если бы для ссылок было 50 сопоставлений пользовательского интерфейса вместо 2, как я показал выше? Я играл со следующим дизайном, но мне он очень не нравится @Test:

public void selectFromLeftBar(String barItem){
  driver.findElement(by.linkText(barItem)).click();
}

Любые мысли будут очень признательны!


person JordanD    schedule 20.08.2013    source источник


Ответы (1)


Сделайте это в своем классе объектов страницы. Вот причины:

  1. Что делает ваш код, если ваша страница меняет текст ссылки? Вы должны пройти каждый тест и изменить этот текст, даже если ссылка делает то же самое.

  2. Что произойдет, если ваша страница удалит эту ссылку? Вы застряли с той же проблемой, а именно с необходимостью находить эту ссылку каждый раз, когда вы звоните. Если это метод... тогда вы удаляете метод, и ваша среда IDE уведомляет вас о каждом экземпляре, который вы использовали.

  3. Наконец, вы предоставляете стандартный интерфейс для теста. Если вы сделаете здесь исключение, что помешает вам передавать на свою страницу другие вещи?

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

person Nathan Merrill    schedule 20.08.2013
comment
Я на 100% согласен. Объектно-ориентированное программирование говорит, что инкапсуляция — это всегда правильный путь. По сути, вы тестируете класс страницы, который является объектным представлением просматриваемой страницы. Кроме того, как сказал MrTi, если вы напишете 100 тестов для этого одного элемента и текст ссылки изменится, вам придется внести 100 правок вместо одной. - person Brantley Blanchard; 21.08.2013
comment
голосование в основном за пункт 2. Изолируя ваши веб-страницы от PageObjects, вы минимизируете влияние при изменении своих веб-страниц. На самом деле наша цель состоит в том, чтобы наши тесты вообще не зависели от Selenium — только наши PageObjects. - person tdrury; 21.08.2013