Сколько нужно переделать при переходе от простой автоматизации к объектной модели страницы с использованием огурцов и селен/капибара?

Question

Моя цель - создать структуру автоматизации объектной модели страницы с использованием огурца с capybara/selenium для проекта клиента mu. В настоящее время мои знания, связанные с жемчужиной Page Object Model, очень ограничены, и в то же время я хочу показать некоторую доставку, создав сценарии автоматизации с использованием огурца и capybara. Поэтому я создаю некоторые файлы функций и последующие определения шагов.

Так что мой вопрос: если я перехожу к простой автоматизации в инфраструктуру POM, то сколько переделок я должен делать с точки зрения сценариев, а также если этот подход правильный. Пожалуйста, направляйте меня, поскольку я довольно новичок в автоматизации рубинов.

Answer 1

Ну это может быть очень упрямым вопросом, но я буду стараться держать его просто:

Если у вас уже есть хорошо структурированный и код (на модульный огурец функции и шаг Defs), он не будет принимать значительный изменения для перехода к POM. Это, по сути, другой метод структурирования, чтобы сохранить свой код организованным и сохранить ваши изменения минимальными/ограниченными.

Драгоценные камни, такие как siteprism, могут помочь вам в создании хорошо структурированных объектов страницы, если вы открыты, чтобы изучить дополнительные DSL (для сайта) на вершине огурца/capybara. Или вы можете использовать свои собственные без каких-либо дополнительных библиотек, хотя это потребует глубокого понимания архитектуры POM и лучших практик.

Надеюсь, что это поможет.

Answer 2

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

В моей работе я помогаю другим QAs учиться и использовать POM за один день, многие парни используют xpath для поиска объектов, я просто показываю, как они могут повторно использовать эти xpaths в объекте страницы.

Второй шаг я показываю использовать метод, а не только элементы, то они могут повторно использовать много кода и остановки повторите шаги, найти, где они ломаются и использовать простой метод в siteprism страницы, например:

element :field_login , :xpath, "login" 
element :field_password, :xpath, "password" 
element :login_button, :xpath, "login_button" 

def authenticate (username, password) 
    field_login.set username 
    field.password.set password 

    LoginPage.new if login_button.click 
end 

Мой следующий шаг - показать, чтобы оставить использовать xpath и использовать элементы css.

И после некоторых спринтов, они понимают преимущества каркаса, и это по умолчанию для всей автоматизации, включая DEV, которые теперь могут понять и помочь в тестах.

Answer 3

Предупреждение, что этот ответ несколько спорный.

Я бы сказал, что не пытайтесь использовать объектную модель страницы, ее принципиально ошибочную. Сеть посвящена ресурсам и представлениям (REST), а не страницам. BDD - это поведение, а не страницы.

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