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

Всем привет.

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

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

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

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

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

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

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

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

Зачем?

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

Зачем?

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

А не могли бы вы приложить еще и пример конфигурационного файла?
И пояснить более подробно про 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);
	    }
	  }

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

.

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

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

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

На мой взгляд следует использовать 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 + "')]");

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

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

На мой взгляд следует использовать 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, гг.