Использование объектов страницы и файлов Config в Selenium

Question

Я использую Ruby Selenium-Webdriver для одного из сценариев автоматизации, которые я разрабатываю, и меня просят использовать объекты страницы, поэтому мы используем объекты страниц, однако для этого Я использую CSV-файл вместо этого, я определил все xpaths, которые я использую в своем приложении в CSV-файле, и я разбираю этот файл CSV в своем скрипте, чтобы ссылаться на эти объекты, я хотел бы знать, есть ли там большая разница в использовании класса для определения объектов страницы или использования CSV-файла вместо того, чтобы влиять на производительность? Я считаю, что использование CSV-файла будет дополнением для нас с точки зрения конфигурации и облегчит его поддержку, любые предложения по этому поводу?

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

Благодаря

Answer 1

Это полностью зависит от применения и тип теста, который вы могли бы выполнить.

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

Сохранение всех свойств идентификации элементов & Соответствующие действия в CSV-файле облегчат обслуживание и сделают независимым рамочное приложение. Но поддерживать свою структуру немного сложно, чтобы сделать ее более надежной. Оба подхода имеют свои плюсы и минусы.

см ниже сообщений [примеры в Java - но вы получите идею]:

1. Keyword driven framework
2. Advanced Page Objects

Update:

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

@ObjectRepository(src="/login.csv") 
public class LoginPage{ 

    private Map<String, WebElement> elements; 

    public void login(){ 
     elements.get("username").sendKeys(''); 
     elements.get("password").sendKeys(''); 
     elements.get("signin").click(); 
    } 
} 

Ie, определить все элементы в конфигурационном файле, как CSV/JSON и т.д. Пусть объект страница относится к классу для элементов страницы. Все методы будут частью класса страницы.

Answer 2

Я думаю, POM лучше, чем подход CSV. В POM вы помещаете элементы для страницы в отдельный файл класса. Таким образом, если какое-либо изменение должно быть сделано, легче найти, где можно изменить/поддерживать. Более того, он не будет слишком беспорядочным, как CSV-файл, и вам не нужно использовать дополнительную функцию утилиты для их анализа.

Answer 3

Существует также жемчужина pageobjects, которая предоставляет набор библиотек поверх webdriver/watir, упрощая код.

Плюс, почему xpaths? Его один из последних рекомендуемых способов идентификации элемента.

Что касается аспекта каркаса, csv должен быть скорее проблемой обслуживания, чем PageObjects. Его основная разница между текстом и кодом.Вы применяете объектно-ориентированный подход к своим элементам в PageObjects, но это невозможно с помощью csv.

В лучшем случае вы создали столбец/отдельные листы, определяющие, к какой странице принадлежит элемент xpath. Это звучит как накладные расходы. По мере роста вашего приложения/набора могут быть тысячи элементов. Представьте себе разбор/ручное обновление csv с такими данными.

Вместо объектов PageObject ваши элементы будут ограничены страницей. Любые изменения в приложении также укажут, какие элементы могут пострадать. Теперь, когда вы определяете свой элемент как объект в PageObject, а не css, вам также не нужно явно создавать свои элементы, читая csv.