Лучший шаблон проектирования для автоматизации Selenium для крупномасштабного применения

Question

Я хотел бы знать лучший шаблон проектирования для Selenium для автоматизации крупномасштабного продукта SaaS.

Ищу все ваши комментарии по этому вопросу.

и для крупномасштабного приложения я предпочел сохранить свой xpath для веб-элементов в объектном файле страницы. но мое руководство хочет, чтобы я оставил xpath в файле свойств, и мы должны получить доступ к файлу свойств для каждого xpath. Это хороший подход для хранения xpath в файле свойств для крупномасштабного SaaS-приложения?

Answer 1

Ваше руководство хочет, чтобы вы внедрили Pattern Repository Pattern.

Я думаю, что эта идея так же стара, как HP QTP (QuickTest Professional), где она широко используется - но я могу ошибаться, это только мое мнение.

Короче (цитата из ссылки выше):

Репозиторий объектов - это централизованное место, где мы можем хранить информацию об объектах, он действует как интерфейс между тестовым скриптом и приложением для идентификации объектов во время выполнения.

---

Мы всегда рекомендуем использовать внешний файл для репозитория объектов, а не жестко кодировать объекты и их свойства непосредственно в нашем коде. Если вы спрашиваете меня, почему это? Причина в том, что это сокращает затраты на обслуживание и обеспечивает положительную рентабельность инвестиций, например, если любое изменение свойств объекта в нашем тестируемом приложении, мы можем легко изменить его в файле репозитория внешних объектов, а не искать и выполнять обновления для этого объекта индивидуально в код

---

Подумайте о сценарии, где у вас есть веб-страница с несколькими разделами, несколькими фреймами и сотнями веб-элементов. Очевидно, что вы не хотите, чтобы, как только вы введете имя страницы, оно предоставит вам все элементы, доступные на веб-странице. Если элементов мало, хорошо иметь одинаковую структуру, но если их много, то желательно разделить страницу на несколько разделов, например, верхний и нижний колонтитулы, левая навигация, центральное содержимое и правая навигация. Затем категории каждого WebElement под их родительским элементом.

---

Я думаю, что этот шаблон не противоречит шаблону объекта Page, они оба могут очень хорошо работать вместе. Это обеспечивает большую прозрачность проекта и вынуждает разработчиков / тестировщиков поддерживать лучшую читаемость проекта, что помогает поддерживать его в будущем.

---

Но вышесказанное является лишь частью теории, можно спросить, как эта модель может помочь в реальной жизни?

Рассмотрим простой пример. Допустим, есть кусок кода:

public class SomePageObject{
   .....
   .....
   public void doSomething(String value){
      findElement( By.xpath("//*[ @class='left-content']//button[ contains( ., 'list-selector' )]") ).click();
      wait.until( ExpectedConditions.visibilityOfElementLocated( By.xpath( String.format( "//li[ *[ text() = '%s' ]]", value ))).click();
}

Я видел такой код сотни раз. Что вы думаете об этом коде?
Да, это следует общеизвестному шаблону объекта страницы. Но это ужасно.
Глядя на этот код, вы можете догадаться, что он делает? Определенно нет.

Какое сообщение об ошибке вы получите в журнале, когда этот код сломается из-за изменения пользовательского интерфейса второго элемента? Скорее всего как то так:

org.openqa.selenium.TimeoutException: Timed out after 30 seconds 
waiting for visibility of element located by By.selector: //li[ *[ text() = 'New York' ]]

Можете ли вы угадать, глядя только на это сообщение об ошибке, какую часть приложения оно касается и где его можно найти в коде? Нет.
Инженер по автоматизации может найти его в коде, просматривающем трассировку стека, но младший тестировщик, который не знает java, selenium и т. Д., Не может исправить это, глядя только на ошибку и экран печати (если доступно).
Во многих случаях для исправления ошибки инженеру-автоматизатору необходимо выполнить этот тестовый пример на локальном компьютере, чтобы воспроизвести проблему.

---

Как это может выглядеть при использовании Object Repository Pattern?
Может быть файл свойств, который может выглядеть так:

....
orderPage.citySelectButton=//*[ @class='left-content']//button[ contains( ., 'list-selector' )]
orderPage.citySelectListElement=//li[ *[ text() = '%s' ]]
...
...

и код, который может выглядеть так:

public class SomePageObject{
   .....
   .....
   public void doSomething(String value){

      objRepoFacade( "orderPage.citySelectButton" ).click();
      objRepoFacade( "orderPage.citySelectListElement", value ).wait().click();
      ...
    )
}

Сообщение об ошибке в журнале может выглядеть так:

RuntimeException: time out waiting for element: orderPage.citySelectListElement
located by By.selector: //li[ *[ text() = 'New York' ]]

И теперь даже младший тестировщик, глядя только на это сообщение об ошибке, может легко угадать, в какой части приложения произошла ошибка, а какой именно элемент поврежден. Тестировщик может быть обучен тому, как проверять элемент на странице с помощью консоли разработчика (F12), исправлять селектор в файле procerties и самостоятельно решать проблему без помощи инженера по автоматизации и вообще не касаться кода.

---

Предположительно, с точки зрения вашего лидера, последний (объектный репозиторий) является лучшим решением, потому что он может использовать больше младших тестировщиков и меньше инженеров по автоматизации и сокращать затраты.