Сообщений в теме: 24

[Helenka]

Здравсвуйте,
я новичок в тестировании и в селениуме.
Тесты на seleniumRC+JUnit. Тестирую веб приложение, которое написано на основе JSF. Проблема в том, что часть ID генерируется автоматически, а часть остается статической. эту статическую часть ID я бы хотела использовать как локатор для элемента. Например, ID = "jsfwmp9169:defaultForm:import:defaultForm:vorname0", vorname0 - статичен и по нему можно было бы найти элемент.
Может кто-нибудь знает, как можно это реализовать, например с помощью AddLocationStrategy.
Или, возможно, вы уже сталкивались с проблемой и решили ее более оптимальным способом.

P.S. XPath не хотелось бы использовать, т.к. приложение еще в стадии разработки. Разработчики пообещали, что часть id будет оставаться постоянной.

Очень надеюсь на помощь!

Заранее спасибо. Елена

[vitorg]

Да, можно написать свой тип селектора, типа "idp=vorname0", который будет искать по части ID. Оптимизированный код поиска элемента по части ID можно подсмотреть в jQuery, например.

[SMakc]

а юзать те же CSS Selectors если уж по непонятным для меня причинам использование XPath противоречит Вашим религиозным соображениями:

css=button[id$='vorname0']

[Helenka]

Спасибо. Поищу что-нибудь подходящее в JQuery. Если у вас есть ссыслка наготове - буду благодарна.
По поводу CSS и XPath: необходимо ведь указывать ID полностью, чтобы референцировать элемент. Или я ошибаюсь? Полностью использовать ID невозможно, т.к. определенная их часть постоянно меняется.

[vitorg]

xpath=//*[contains(@id, 'vorname0')], но этот способ немного кривоватый.

PS: "референцировать" - еле произнёс

[Helenka]

Доброе утро,
у меня возникла еще одна проблемка с ID, может у кого-нибудь есть идея. Строки в таблице генерируются автоматически и только имя таблицы остается постоянным (asyncTable1).
(jsfwmp7795:defaultForm:import:defaultForm:asyncTable1:__rowAlexandridisBenWedu_0020_Sepu_0020_19u_0020_00u_003a_00u_003a_00u_0020_CESTu_0020_2007:selectRowOnClick) - это ID radiobutton.
Пока даже понятия не имeю, как мне работать с этими таблицами и как однозначно выбирать ее элементы.
Если была у вас такая же проблема и вы ее решили, подскажите, пожалуйста.

P.S. слово "референцировать" буду в будущем избегать)))

[OVA]

1. Научить разработчиков делать человеческие ID даже в этом случае.
2. Поискать другие способы локейтить. Их много, потому без кода странички оно как-то не очень понятно какой лучше/удобнее. Да и без постановки задачи тоже.

[Helenka]

1. вариант с разработчиками, к сожалению, не пройдет (((
2. Постановка задачи:
Надо в таблице найти по имени (например как в скриншоте "Alexandridis, Ben") соответствующую строку и radiobutton и активировать его.
Для нахожденя radiobutton можно использовать записанное ID (точнее те его части, которые остаются постоянными) и имя (н-р "Alexandridis, Ben").

[vitorg]

Просто надо XPath по которому кликаем похитрее написать, типа такого: xpath=//tr[td[text()='Alexandridis, Ben']]/td[1]/input[@type='radio'].

А вообще по-моему стоит придерживаться стратегии: автотесты не должны влиять на тестируемый код. Т.е. просить разработчиков писать код иначе, ссылаясь на ограничения своего инструмента - это плохо, тем более, что у Selenium в этом смысле практически нет ограничений.

[OVA]

Писать плохие локаторы просто потому что других никак не получается это верный путь к плохо поддерживаемым тестам. Может я не прав, но обычно так получается. К тому же для части софта локаторы по тексту это натуральное самоубийство, потому что локализация. И в общем-то работы для разработчика тут не сильно много как правило (можно и самим проставить, если уж совсем приперло), а на выходе получаем человеческие тесты, а не набор костылей.

[Helenka]

Объясните, пожалуйста, для еще совсем "зеленых" в тестировании, чем так плоха локализация по тексту. Я пишу диплом по этой теме, и разработка автоматизированных тестов - его часть.
И хотелось бы еще узнать ваше мнение по этому поводу: мои тесты извлечены из программы и хранятся в виде XML-файлов, программа грузит эти тесты, parser считывает и выполняет соответствующие команды. Сделано это - чтобы облегчить поддержку тестов - через редактирование XML, а не кода программы. Записал тест на IDE, трансформировал его в XML, добавил псевокод. Так как тестируемое приложение в будущем будет еще дорабатываться и переделываться, необходимы тесты, которые бы легко поддерживались. Дополнительные операции, которых нет в selenium, добавляются к xml вручную как псевдокод (например создание определенного состояние базы данных (fixture)). Тестовые данные хранятся тоже в отдельных xml-файлах.

Кусочек тестового файла:
<selenese>
<command>type</command>
<target><![CDATA[jsf111:defaultForm:import:defaultForm:vorname0]]></target>
<value><![CDATA[$kind/vorname]]></value>
</selenese>
Недеюсь у меня получилось донести идею.

[OVA]

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

Собственно примеры:
1. Локализация (очень не круто когда вы не можете легко взять и прогнать те же тесты под другой локалью).
2. Минорные изменения в приложении (кнопку переименовали с OK на Confirm - ловите false positive). В вашем случае поменяете формат вывода имени/фамилии и уже оп-па. А если она еще и настраиваемой станет, то количество го... не очень хорошего кода вырастет в разы.
3. Кроссбраузерность

Это все лечится. Риски минимизируются. Но все равно это костыли которых можно избежать обеспечив Testability продукта.

Вот еще можно почитать для общего развития почему лучше все же человеческие id получать/делать: http://blogs.atlassi...n_worth_it.html


Про поддержку и прочее - не нужно городить огород с псевдокодом и xml. Лучше сразу переходите на Selenium RC и там делайте человеческий код тестов с человеческой же структурой.

[Helenka]

Дело в том, что на selenium RC переход уже совершен. Parser (java) считывает команды и отправляет их SeleniumRC. Тесты только находятся вне приложения.

[OVA]

BDD?

[Helenka]

BDD = Behavior driven development?

[OVA]

Угу. Я просто не очень понимаю зачем иначе такое городить)

[Helenka]

Потому что руководители такого мнения, что тесты и последовательность действий селениума не должна быть "hard coded". Чтобы в любой момент с помощью обычного текстового редактора можно было подправить тесты или дописать новые, не компилируя и не деплоя тестовое приложение заново. Как-то так.

[OVA]

Оу. Ну просто проще написать кучу библиотечек для тестов, а потом уже писать код тестов. Они в идеале будут не сильно отличаться внешне от API тестов и можно будет ко всему еще наслаждаться всякими TestNG без плясок с бубном.

И да, тестовое приложение это Sistem Under Test или что?

[Helenka]

Не, тестовое приложение - это моя программка, которая тестирует System Under Test

[enki86]

ересь какая-то...
зачем заново придумывать dependуncy injection ?
Куча хороших фреймворков, которые уже написаны, опробованы и хороши настолько, что ими пользуются. Возьмите хотя бы тот же TestNG для java. Парсер - это лишняя нагрузка и замедление работы тестов.

Зачем?