Перейти к содержимому

Фотография

Минимизация работы при изменение id или имени элементов.


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 11

#1 soleksenko2702

soleksenko2702

    Постоянный участник

  • Members
  • PipPipPip
  • 193 сообщений
  • ФИО:Олексенко Сергей

Отправлено 24 января 2012 - 07:36

Всем привет.

Недавно начал заниматься selenium.
Интересует ситуация кто как справляется с изменениями в коде страницы. Я имею ввиду когда по каким то причинам может измениться id или имя элемента.
Как лучше решить эту проблему? По всему коду менять id очень неудобно.
Есть мысль делать это в каком то конфигурационном файле.
Кто что может рассказать по этому поводу?
  • 0

#2 OVA

OVA

    Опытный участник

  • Members
  • PipPipPipPip
  • 405 сообщений
  • ФИО:Высоцкий Сергей Павлович
  • Город:Новосибирск

Отправлено 24 января 2012 - 07:48

Если вкратце, то гуглить по вот этой фразе: Page Objects

Вот отсюда примерно копать: http://code.google.c...iki/PageObjects
Примеров на любых языках программирования в интернетах море.

Конкретные реализации и вещи типа Polymorphous Page Objects по мере надобности, как поймете чего еще вам не хватает.
  • 0

#3 neman

neman

    Активный участник

  • Members
  • PipPip
  • 142 сообщений
  • ФИО:Антон


Отправлено 24 января 2012 - 08:07

Хранить локаторы в конфигах на мой взгляд это всегда полезно, независимо от выбранного паттерна проектирования. Лично реализовал это следующим образом: все локаторы элементов хранятся в одной папке в нескольких конфигах (логически разбитых по частям системы). Вызываемый в начале тестов класс подтягивает все конфиги из указанной папки и предоставляет метод для получения значений локатора. В качестве своего рода "сахара" - расширение класса By (это если использовать selenium WebDriver), которое переопределяет методы так, чтобы они сначала пытались найти указанное значение в конфигах. В результате вызов элемента выглядит так - driver.findElement(ByExt.id("StartProcess.Directive.startDate")), плюс надо прописать строчку в конфиге. То есть в результате вид тестов не усложняется, да и можно локаторам давать понятные имена.
  • 0

#4 soleksenko2702

soleksenko2702

    Постоянный участник

  • Members
  • PipPipPip
  • 193 сообщений
  • ФИО:Олексенко Сергей

Отправлено 24 января 2012 - 08:45

Хранить локаторы в конфигах на мой взгляд это всегда полезно, независимо от выбранного паттерна проектирования. Лично реализовал это следующим образом: все локаторы элементов хранятся в одной папке в нескольких конфигах (логически разбитых по частям системы). Вызываемый в начале тестов класс подтягивает все конфиги из указанной папки и предоставляет метод для получения значений локатора. В качестве своего рода "сахара" - расширение класса By (это если использовать selenium WebDriver), которое переопределяет методы так, чтобы они сначала пытались найти указанное значение в конфигах. В результате вызов элемента выглядит так - driver.findElement(ByExt.id("StartProcess.Directive.startDate")), плюс надо прописать строчку в конфиге. То есть в результате вид тестов не усложняется, да и можно локаторам давать понятные имена.


А не могли бы вы приложить еще и пример конфигурационного файла?
И пояснить более подробно про ByExt?
  • 0

#5 OVA

OVA

    Опытный участник

  • Members
  • PipPipPipPip
  • 405 сообщений
  • ФИО:Высоцкий Сергей Павлович
  • Город:Новосибирск

Отправлено 24 января 2012 - 10:16

Хранить локаторы в конфигах на мой взгляд это всегда полезно, независимо от выбранного паттерна проектирования.

Зачем?
  • 0

#6 neman

neman

    Активный участник

  • Members
  • PipPip
  • 142 сообщений
  • ФИО:Антон


Отправлено 24 января 2012 - 10:31


Хранить локаторы в конфигах на мой взгляд это всегда полезно, независимо от выбранного паттерна проектирования.

Зачем?

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

#7 neman

neman

    Активный участник

  • Members
  • PipPip
  • 142 сообщений
  • ФИО:Антон


Отправлено 24 января 2012 - 10:44

А не могли бы вы приложить еще и пример конфигурационного файла?
И пояснить более подробно про ByExt?

Конфиг - обычный джавовский .properties, с записями <имя локатора> = <значение локатора>.
ByExt - это расширение стандартного класса By, с переопределенными методами id, name, xpath и т.д.
Выглядит это примерно так (Java):
public abstract class ByExt extends By
{
	public static By id(final String id) 
	{
	    if (id == null)
	      throw new IllegalArgumentException(
	          "Cannot find elements with a null id attribute.");
	    else
	    {
	    	try {
				if (ConfigReader.getProperty(id) != null)
					return new ById(ConfigReader.getProperty(id));
			} catch (Exception e) {;}
				return new ById(id);
	    }
	  }
Т.е. никакой особой магии. Если у нас в пропертях есть локатор с таким названием, то используем его значение (как читать из таких файлов - это уже особенности языка). Если же нет, то проглатываем исключение и используем в качестве локатора переданную строку - удобно для отладки.
  • 0

#8 neman

neman

    Активный участник

  • Members
  • PipPip
  • 142 сообщений
  • ФИО:Антон


Отправлено 24 января 2012 - 10:46

.

Сообщение отредактировал neman: 24 января 2012 - 10:46

  • 0

#9 OVA

OVA

    Опытный участник

  • Members
  • PipPipPipPip
  • 405 сообщений
  • ФИО:Высоцкий Сергей Павлович
  • Город:Новосибирск

Отправлено 24 января 2012 - 11:03

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

У меня есть PageObject. У меня в нем нормально, структурировано описаны все нужные мне элементы и действия на странице. У меня есть тесты, где никаких локаторов нет и быть не должно.
ЧЯДНТ? Зачем туда еще и конфиги? Зачем плодить сущности?
  • 0

#10 Reunion

Reunion

    Новый участник

  • Members
  • Pip
  • 9 сообщений
  • ФИО:Кротов Анатолий
  • Город:Харьков


Отправлено 24 января 2012 - 15:58

На мой взгляд следует использовать Page Object, т.к. довольно часто мне приходиться делать в методах, например, вот такие вещи:

int checkOutDay = calendar.get(Calendar.DAY_OF_MONTH);
int checkOutMonth = calendar.get(Calendar.MONTH);
int checkOutYear = calendar.get(Calendar.YEAR);

selenium.select("//div[@id='ui-datepicker-div']/div/div/select[2]",
		"value=" + month.get(checkOutMonth) + "_" + checkOutYear);
selenium.click("//a[contains(text(),'" + checkOutDay + "')]");
т.е. разбивать локаторы на части, для динамической их генерации. Для этих целей, как мне кажется, проперти-файл не очень удобен.
  • 0
Life is too short for manual testing...

#11 OVA

OVA

    Опытный участник

  • Members
  • PipPipPipPip
  • 405 сообщений
  • ФИО:Высоцкий Сергей Павлович
  • Город:Новосибирск

Отправлено 24 января 2012 - 18:03

FFS? //div[@id='ui-datepicker-div']/div/div/select[2]
  • 0

#12 Wolonter

Wolonter

    Постоянный участник

  • Members
  • PipPipPip
  • 205 сообщений
  • ФИО:Макс
  • Город:Екатеринбург


Отправлено 25 января 2012 - 04:43

На мой взгляд следует использовать Page Object, т.к. довольно часто мне приходиться делать в методах, например, вот такие вещи:

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


Локаторы храним в классе драйвера объекта. С локаторами, побитыми на части живем примерно так:

Переопределили метод:
public void clickElement(String xpath, Object... args)
{
clickElement(By.xpath(textFormat(xpath, args)));
}

И пользуемся так:
tester.clickElement(AttrUtils.EDIT_BUTTON, attr.get(AttrModel.CODE));
или так:
tester.clickElement(AttrUtils.OK_BUTTON));
где:
public static final String EDIT_BUTTON = "//*[@id='gwt-debug-%s.editButton']/a";
public static final String OK_BUTTON = "//div[@id='gwt-debug-ok']";

UPD: Да, а у нас НЕ Page Object, гг.
  • 0


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных