Page Object Model (POM)

Что такое объектная модель страницы?

Объектная модель страницы — это шаблон проектирования, в котором основное внимание уделяется сокращению дублирования кода и минимизации усилий, связанных с обновлением/обслуживанием кода. В объектной модели страницы классы страниц создаются для всех веб-страниц, которые являются частью тестируемой автоматизации (AUT).

Это делает код более модульным, поскольку локаторы/элементы , используемые комплектами тестов/сценариями тестов, хранятся в отдельном файле класса, а тестовые примеры (содержащие основную логику тестирования) находятся в другом файле. Следовательно, любые изменения в элементах веб-интерфейса потребуют минимальных изменений (или их отсутствия) в тестовых сценариях, поскольку локаторы и тестовые сценарии хранятся отдельно.

Зачем использовать объектную модель страницы (POM)?

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

Веб-продукт (или проект) состоит из различных веб-страниц, которые используют различные веб-элементы (например, элементы меню, текстовые поля, флажки, переключатели и т. д.). Тестовые случаи будут взаимодействовать с этими элементами, и сложность кода многократно возрастет, если локаторы Selenium не будут управляться должным образом.

Преимущества объектной модели страницы(POM)

Теперь, когда вы знакомы с основами объектной модели страницы, давайте рассмотрим некоторые из основных преимуществ использования этого шаблона проектирования:

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

• Улучшенная ремонтопригодность . Поскольку тестовые сценарии и локаторы хранятся отдельно, это делает код чище, и меньше усилий тратится на поддержку тестового кода.

• Минимальное влияние из-за изменений пользовательского интерфейса . Даже если в пользовательском интерфейсе происходят частые изменения, изменения могут потребоваться только в репозитории объектов (где хранятся локаторы). Влияние на реализацию тестовых сценариев минимально или отсутствует.

• Интеграция с несколькими средами тестирования . Поскольку реализация теста отделена от репозитория объектов страниц (или классов страниц), мы можем использовать один и тот же репозиторий с разными средами тестирования. Например, Test Case — 1 может использовать фреймворк Robot, Tese Case — 2 может использовать фреймворк pytest и т. д. Один набор тестов может содержать тестовые случаи, реализованные с использованием разных фреймворков тестирования .

Пример POM:

from selenium.webdriver.common.by import By
from Src.PageObject.Locators import Locator

class Home(object): 
    def init(self, driver): 
        self.driver = driver
        self.logo = driver.find_element(By.XPATH, Locator.logo)
        self.search_text = driver.find_element(By.XPATH, Locator.search_text)
        self.submit = driver.find_element(By.XPATH, Locator.submit)

    def getSearchText(self):
        return self.search_text

    def getSubmit(self):
        return self.submit

    def getWebPageLogo(self):
        return self.logo