Подтвердить что ты не робот

Оптимальная практика объектной модели страницы в селене

Когда вы моделируете объекты страницы, как вы будете обрабатывать страницу с формой и около 50 полей ввода? Какая здесь самая лучшая практика?

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

например.

public void enterFirstName(String firstName) {
    driver.type("firstNameField", firstName);
}

public void enterSecondName(String secondName) {
    driver.type("secondNameField", secondName);
}

или

public void fillInForm(String inputFieldName, String text) {
    driver.type(inputFieldName, text);
}

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

Этот пост также весьма интересен при структурировании тестов селена в Page Object Функциональное автоматизированное тестирование с использованием Selenium WebDriver

4b9b3361

Ответ 1

Мне всегда нравится разбивать вещи на группы связанной информации. Например, если у меня есть пользовательский класс, я мог бы разбить его на несколько меньших классов: LoginCredentials, ProfileInfo, Settings и т.д., Но я бы обычно имел класс пользователя верхнего уровня, который содержит эти подклассы.

Одна вещь, которую я бы рекомендовал, - это передать объект одной функции FillForm, а не все эти отдельные функции. При таком подходе есть некоторые большие преимущества. Во-первых, у вас могут быть некоторые "общие" предварительно сконфигурированные объекты, которые вы используете для многих ваших тестовых случаев. Например:

public class FormInfo
{
   string Domain;
   string Name;
   string Category;
   // etc...

  public FormInfo(string domain, string name, string category)
  {
     Domain = domain;
     Name = name;
     Category = category;
     // etc...
  }
}


// Somewhere in your initialization code
public static FormInfo Info1 = new FormInfo("myDomain1", "myName1", "myCategory1");
public static FormInfo Info2 = new FormInfo("myDomain2", "myName2", "myCategory2");

You can still update one of your common merchants if you need to do something one-off:

// In your test case:
Info1.Category = "blah";
FormPage.FillForm(Info1);

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

Info1.Domain = null; //This should make the FillForm function skip doing anything with this field.
FormPage.FillForm(Info1);
FormPage.DomainTextBox.Text = "field validation string";

Другим важным преимуществом этого подхода является то, что если страница постоянно обновляется, чтобы добавлять, удалять или изменять поля, вам нужно будет только обновить свой объект FormInfo и функцию FillForm и не нужно будет изменять конкретные тестовые примеры, вызывающие FillForm - при условии, что они используют один из ваших общих объектов FormInfo. Другой возможностью получить больше информации было бы создание одного из ваших общих объектов FormInfo для генерации случайных строк для каждого из полей, которые соответствуют длине min/max и цикла между всеми разными допустимыми символами. Это позволяет вам получить дополнительное тестирование из одного и того же набора тестов, хотя оно также может добавить некоторый шум, если вы начнете получать результаты отказа только от определенных строк, поэтому будьте осторожны.

Ответ 2

Идея объектной модели страницы заключается в том, что она абстрагирует реализацию от вызывающего. В первом механизме вы успешно это делаете, потому что вызывающему абоненту не нужно знать, изменяется ли имя поля ввода html с "firstName" на "user_first_name", тогда как во второй реализации любые изменения на фактической странице должны быть просочился всем вызывающим пользователям вашего объекта страницы.

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

Ответ 3

В дополнение к вашим методам enterWhatever() я обычно также создаю метод createWhatever(field1, field2, ...), который я могу использовать в качестве быстрого пути к созданию любых построений форм, для использования, когда цель real теста - это что-то другое. Таким образом, если мне нужно создать Клиента, чтобы проверить отправку Билета, тест переходит на страницу CreateACustomer и просто вызывает createCustomer(firstName, lastName, emailAddress, ...), а затем переходит к более тонкой задаче создания Билета с использованием этого Клиента.

Ответ 4

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

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

что это сводится к тому, что все, что я должен сделать, чтобы проверить страницу, таково:

for (int i = 0; i < inputs.Count(); i++)
{
  //This captures the error message string created in the input validation method
  //nextButton is the IWebElement of the button to click to submit the form for validation
  //ErrorMessageID is the ID of the Validation Summary display box (i.e. ErrorMessageID = "FormSummary" <asp:ValidationSummary ID="FormSummary" runat="server" CssClass="errorMessage" />

  string InputValidationText = utilities.InputValidation(driver, inputs, i, nextButton, ErrorMessageID)
  if(InputValidationText != string.Empty)
  {
    //LogError
  }
}

Ответ 6

Я отвечаю на старый вопрос на благо читателей.

Наряду с другими хорошими ответами здесь я хотел бы добавить несколько предложений здесь для тех, кто новичок в POM.

Объекты страницы - это хорошо известный шаблон проектирования, широко используемый специалистами по автоматизации, для создания отдельного файла класса для каждой страницы приложения для группировки всех элементов как свойств и их поведения/бизнес-функций в качестве методов класса. Но у него мало проблем при создании класса для страницы - особенно, когда на странице больше/разных наборов элементов/сложных элементов, таких как виджет сетки/календаря/таблица HTML и т.д.

Класс может содержать слишком много обязанностей для обработки. Он должен быть реструктурирован и разбит на более мелкие классы. То есть, следуя Ответственность за единую ответственность.

Проверьте изображение здесь для идеи.

введите описание изображения здесь

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

Подробнее о здесь для получения дополнительной информации.