Недавно в свободное время наклепал проектик, в котором консолидировал весь свой опыт накопленный в области тестирования через UI.
Принципы, которыми руководствовался в процессе написания проекта:
1) Тесты должны быть простыми в написании и поддержке
2) Тесты должны быть легкочитаемы
3) Сайт должен содержать AJAX и тесты должны справлятся с этим
4) Решение проблем с постоянностью. Это значит что тесты к примеру добавили юзера с именем "User1" в базу, то при втором запуске они не должны свалится от того что такой юзер уже сужествует.
5) При ошибках тесты должны выдавать правильные ошибки, четко указывающие в чем проблема
6) Генерация кода, чтобы уменьшить количество работы
7) Должна быть возможность написания тестов непрограммистами
8) Уменьшение времени тестирования путем запуска тестов в параллельных потоках, и используя Selenium Grid
Здравствуйте, sLMoloch, Вы писали:
LM>Всем привет,
LM>Недавно в свободное время наклепал проектик, в котором консолидировал весь свой опыт накопленный в области тестирования через UI.
Вы уточняйте, что это опыт тестирования UI с использованием Selenium-а, с примерами конкретных реализаций на C#.
Но это так, мелочь. У меня есть опыт работы с Selenium-ом, но только на Java и Ruby. Тем не менее, есть ряд общих вещей, которые мало зависят от конкретного языка.
LM>Принципы, которыми руководствовался в процессе написания проекта:
LM>1) Тесты должны быть простыми в написании и поддержке LM>2) Тесты должны быть легкочитаемы
Тут еще надо определиться с целевой аудиторией. У нас на одном из проектов тоже одной из целей дизайна была простота, легкость поддержки и чтения тестов. Для этих целей делалось расширение основного класса Selenium-клиента, когда в те же методы верификаций, типа isTextPresent, уже встявлялись assert-ы. И сами тестовые классы наследовались от этого расширенного клиента. То есть, разработчик тестов вполне мог использовать методы селениума, даже не догадываясь, откуда они вообще там доступны.
И еще один момент. Как показала практика, для мануальщиков ООП весьма трудно для понимания. Гараздо проще именно процедурное программирование. В результате тест представляет собой последовательность команд вида:
Идея оконных объектов достаточно удобна, мы ее тоже использовали. С той разницей, что в Java нет properties. Соответственно, пришлось использовать методы, причем они созвучны с методами Selenium-а, выполняющими основной ввод. То есть, все методы, которые делали клик начинались, с click, например clickOnSubmitButton(). По аналогии в соответствующих методах использовалиьсь префиксы type, select. Если бы в Java были properties, то ввод текста, выбор значения из списка точно были бы реализованы так же, как и у вас.
Причем, если то или иное действие приводило к загрузке другой страницы, то данный методы возвращали объект страницы. Соответственно, навигаторы, которые использовали вы, в данной задаче не использовались.
Если надо было делать навигацию через несколько страниц, то для этого резервировались отдельные классы (в зависимости от модуля), которые содержали методы, осуществляющие нужную последовательность переходов с возвратом соответствующего объекта страницы.
LM>3) Сайт должен содержать AJAX и тесты должны справлятся с этим LM>4) Решение проблем с постоянностью. Это значит что тесты к примеру добавили юзера с именем "User1" в базу, то при втором запуске они не должны свалится от того что такой юзер уже сужествует.
У вас приведен пример считывания данных из базы, получение информации о существующих данных, хотя то, что вы описываете, может иметь много других подвидов.
Для этого нужно реализовать ряд recovery-сценариев. Как правило, это сценарии нескольких типов:
1) Установка основных настроек — используется какое-то средство администрирования тестируемого приложения, в котором выставляются все необходимые настройки, так что ни один тест, который как-то с такими настройками играется, не повлияет на работу других тестов.
2) Установка настроек, специфических для некоторой группы тестов — как правило, к ним в комплект идут сценарии, которые восстанавливают настройки по умолчанию, особенно, если это конфигурация, которая не накрывается сценарием из пункта 1.
3) Импорт данных, если таковые отсутствуют. Зачастую импорт предусматривает перезапись уже существующих данных.
LM>5) При ошибках тесты должны выдавать правильные ошибки, четко указывающие в чем проблема
Это скорее по части соглашений по написанию текста ошибок. Чем более детален текст описания, тем легче понять, что же произошло. Самый простой пример: если есть расхождения между ожидаемыми и фактическими результатами, то указываются оба: и что ожидали и что получили.
Есть еще штуки, специфические для конкретных ЯП. Например, для Ruby есть тестовый движок Cucumber, который использует Requirement Driven Testing подход. Так его лог выводит результаты не просто с текстом ошибок, а еще и с шагами для воспроизведения. Но это за счет особенности дизайна тестов для данного движка.
LM>6) Генерация кода, чтобы уменьшить количество работы
О да. Генерация — это всегда круто. Но в примерах, на которые вы ссылаетесь по данному пункту, вы используете исключительно xpath. На практике подобные локаторы одни из самых вредных, так как и работают медленней, а также более чувствительны к изменениям UI, особенно если захватывается несколько элементов в DOM-структуре.
LM>7) Должна быть возможность написания тестов непрограммистами
Я об этом упомянул выше. "Непрограммисты" зачастую с трудом воспринимают ООП. Процедурный вызов попроще. Это исходя из моих личных наблюдений. Поэтому, либо поменьше наворотов, либо их заправить так, чтоб "непрограммист" и близко не видел, откуда что берется, а просто знал, что можно выбрать.
LM>8) Уменьшение времени тестирования путем запуска тестов в параллельных потоках, и используя Selenium Grid
Кстати, есть еще и т.н. практика "чёртового колеса", когда тесты выполняются постоянно в бесконечном цикле. Средства автосборки подобное обеспечивают. Главное — создать 2 идентичные таски, каждая из которых запускает тесты и выдает нотификации. При этом как только заканчивается выполнение первой таски, то начинается вторая. А когда закончится вторая, то начинается первая.
В чем преимущество: тесты работают 24 часа в сутки 7 дней в неделю. Человек работает 8 часов 5 дней в неделю. Даже если учесть, что автотесты работают в том же темпе, что и выполняются вручную, то от такой разницы по времени мы получаем выигрыш ( 24 * 7 )/( 8 * 5 ) = 21/5 = 4.2
То есть, работа одной машины заменяет работу 4-х людей. Особенно хорошо это себя проявит, когда суммарное время выполнения тестов будет исчисляться неделями.
Помимо этого, использование подобной практики позволит вам оперативно выявить реальные ошибки ваших тестов, то есть, если тест из разряда "passed after re-run", то при таких запусках 2-3 прогона подобные тесты отсеют.
В целом, ваше решение достаточно хорошее. У нас тут скоро планируется использовать селениум как раз в связке с .NET. Я думаю, выложенный вами материал будет интересен для ознакомления тем ребятам, которые на этом проекте будут работать.
Re[2]: Дизайн Selenium Web тестов для ASP.NET на C#
M>Вы уточняйте, что это опыт тестирования UI с использованием Selenium-а, с примерами конкретных реализаций на C#.
Тема называется "Дизайн Selenium Web тестов для ASP.NET на C#", но наверное да, надо было продублировать в тексте.
LM>>Принципы, которыми руководствовался в процессе написания проекта:
LM>>1) Тесты должны быть простыми в написании и поддержке LM>>2) Тесты должны быть легкочитаемы
M>Тут еще надо определиться с целевой аудиторией. У нас на одном из проектов тоже одной из целей дизайна была простота, легкость поддержки и чтения тестов. Для этих целей делалось расширение основного класса Selenium-клиента, когда в те же методы верификаций, типа isTextPresent, уже встявлялись assert-ы. И сами тестовые классы наследовались от этого расширенного клиента. То есть, разработчик тестов вполне мог использовать методы селениума, даже не догадываясь, откуда они вообще там доступны.
Тут немного не понял, что имеется ввиду под целевой аудиторией?
M>И еще один момент. Как показала практика, для мануальщиков ООП весьма трудно для понимания. Гараздо проще именно процедурное программирование. В результате тест представляет собой последовательность команд вида:
M>click( "some_locator" ); M>isTextPresent( "Some text" ); M>isElementPresent( "some_other_locator" );
M>И так далее.
Согласен на 100%. Поэтому для непрограммистов был разработан особой тип тестов — скриптовый, который пишется в любом текстовом редакторе. Например (Здесь файл):
GoToLoginPage
EnterCredentials admin god
Login
Заметьте что в скрипте не фигурирует никаких локаторов и аспектов работы с тем же AJAX — это не дело мануальщиков и бизнес людей.
M>Идея оконных объектов достаточно удобна, мы ее тоже использовали. С той разницей, что в Java нет properties. Соответственно, пришлось использовать методы, причем они созвучны с методами Selenium-а, выполняющими основной ввод. То есть, все методы, которые делали клик начинались, с click, например clickOnSubmitButton(). По аналогии в соответствующих методах использовалиьсь префиксы type, select. Если бы в Java были properties, то ввод текста, выбор значения из списка точно были бы реализованы так же, как и у вас. M>Причем, если то или иное действие приводило к загрузке другой страницы, то данный методы возвращали объект страницы. Соответственно, навигаторы, которые использовали вы, в данной задаче не использовались.
Дело в том, что при кликах приходится выполнять очень много одинаковых действий, таких как
1) Ассерт того что мы заредиректались / не заредиректались на нужную страницу
2) Вывод "информативной ошибки" в случае редиректа на страницу с ASP.NET ошибкой
3) Ожидание AJAX
Да и Page Objects по идее не должны заниматся ни чем кроме инкапсуляции доступа к элементам страницы (SRP), поэтому вся ответственность по переходам по страницам была переложена на навигатор.
M>Если надо было делать навигацию через несколько страниц, то для этого резервировались отдельные классы (в зависимости от модуля), которые содержали методы, осуществляющие нужную последовательность переходов с возвратом соответствующего объекта страницы.
Да, это очень удобно — в дaнном проекте это сделано с Flows:
public LoginPageFlow EnterCredentials(string name, string password)
{
_login.User.SetText(name);
_login.Password.SetText(password);
return this;
}
public HomePageFlow Login()
{
var homePage = Navigator.Navigate<HomePage>(_login.ClickLogin);
return new HomePageFlow(Navigator, homePage);
}
Использование:
[Test]
public void LoginSuccessWithCorrectPassword()
{
using (var start = GetStart())
{
start
.GoToLoginPage()
.EnterCredentials("admin", "god")
.Login();
}
}
M>У вас приведен пример считывания данных из базы, получение информации о существующих данных, хотя то, что вы описываете, может иметь много других подвидов.
M>Для этого нужно реализовать ряд recovery-сценариев. Как правило, это сценарии нескольких типов: M>1) Установка основных настроек — используется какое-то средство администрирования тестируемого приложения, в котором выставляются все необходимые настройки, так что ни один тест, который как-то с такими настройками играется, не повлияет на работу других тестов. M>2) Установка настроек, специфических для некоторой группы тестов — как правило, к ним в комплект идут сценарии, которые восстанавливают настройки по умолчанию, особенно, если это конфигурация, которая не накрывается сценарием из пункта 1. M>3) Импорт данных, если таковые отсутствуют. Зачастую импорт предусматривает перезапись уже существующих данных.
Вот! Я знал что что-то забыл! Спасибо за напоминание — обязательно добавлю.
LM>>5) При ошибках тесты должны выдавать правильные ошибки, четко указывающие в чем проблема M>Это скорее по части соглашений по написанию текста ошибок. Чем более детален текст описания, тем легче понять, что же произошло. Самый простой пример: если есть расхождения между ожидаемыми и фактическими результатами, то указываются оба: и что ожидали и что получили.
Кроме этого, есть еще вещи, которые надо учесть. К примеру после логина мы проверяем что на домашней странице выводится имя залогиненного юзера. Но если мы не залогинились (свалилась процедура логина), то у нас будет Selenium ексепшен о том что элемент с именем "username" не найден. Что здесь в message для assert класть? Не понятно отчего этого элемента нет — кто то его просто удалил или процедура логина не прошла? а если не прошла — то из-за чего?
Поподробнее здесь
M>Есть еще штуки, специфические для конкретных ЯП. Например, для Ruby есть тестовый движок Cucumber, который использует Requirement Driven Testing подход. Так его лог выводит результаты не просто с текстом ошибок, а еще и с шагами для воспроизведения. Но это за счет особенности дизайна тестов для данного движка.
Лог с шагами для воспроизведения — это очень интересно, спасибо за идею. А вообще селениум тесты можно пускать и из BDD фреймворков, но имхо это не очень удобно.
LM>>6) Генерация кода, чтобы уменьшить количество работы M>О да. Генерация — это всегда круто. Но в примерах, на которые вы ссылаетесь по данному пункту, вы используете исключительно xpath. На практике подобные локаторы одни из самых вредных, так как и работают медленней, а также более чувствительны к изменениям UI, особенно если захватывается несколько элементов в DOM-структуре.
Никто не мешает использовать ID в параметрах к кодогенератору, это же только пример. XPath там используется только ради удобства. Мы заметили что очень много времени уходит на поиск добавившихся/изменившихся контролов в странице, и вписывание их в Page Object. В данном проекте просто открываешь страницу в FF, находишь все инпуты по паттерну "//input" , кидаешь результат в кодогенератор и вуаля — у тебя уже готовый Page Object. Если что-то изменилось на странице, то ошибки компиляции позволяют с легкостью найти все проблемные места.
Плюс к тому без Xpath никак не обратишься к тексту в любой строке внутри грида(
А насчет скорости работы — это довольно спорный вопрос, я по крайней мере спада в перформансе не заметил.
LM>>7) Должна быть возможность написания тестов непрограммистами
M>Я об этом упомянул выше. "Непрограммисты" зачастую с трудом воспринимают ООП. Процедурный вызов попроще. Это исходя из моих личных наблюдений. Поэтому, либо поменьше наворотов, либо их заправить так, чтоб "непрограммист" и близко не видел, откуда что берется, а просто знал, что можно выбрать.
Согласен. Тут есть маленькая проблема со скриптом выше — надо знать что туда писать — то есть как минимум иметь систему справки о доступных из данного состояния переходах, а в идеале тулзу, которая позволяет собирать тесты как конструктор лего) К счастью инфу для создания одного и другого легко выделить из описания Flow классов, и является делом времени и техники.
LM>>8) Уменьшение времени тестирования путем запуска тестов в параллельных потоках, и используя Selenium Grid
M>Кстати, есть еще и т.н. практика "чёртового колеса", когда тесты выполняются постоянно в бесконечном цикле. Средства автосборки подобное обеспечивают. Главное — создать 2 идентичные таски, каждая из которых запускает тесты и выдает нотификации. При этом как только заканчивается выполнение первой таски, то начинается вторая. А когда закончится вторая, то начинается первая.
Мне почему то кажется что это просто пустая трата ресурсов — запускать по нескольку раз один сет тестов на одну ревизию кода. Если предполагается что тесты могут сработать по разному на одном и том же срезе кода, то что-то не в порядке с тестами — и эту проблему надо срочно решать, так как такие результаты не будут приниматся всерьез программистами. Типа — ну свалилось и хрен с ним, на следующий запуск глядишь сработают.
M>В чем преимущество: тесты работают 24 часа в сутки 7 дней в неделю. Человек работает 8 часов 5 дней в неделю. Даже если учесть, что автотесты работают в том же темпе, что и выполняются вручную, то от такой разницы по времени мы получаем выигрыш ( 24 * 7 )/( 8 * 5 ) = 21/5 = 4.2
M>То есть, работа одной машины заменяет работу 4-х людей. Особенно хорошо это себя проявит, когда суммарное время выполнения тестов будет исчисляться неделями.
Работу машины нельзя никоим образом сравнивать с работой реальных людей — только потому что машина проверит тока то что предписано, но не заметит что потек где-то дизайн, половину контролов не видно. Да и невозможно на 100% автоматизировать все функциональные тесты.
M>Помимо этого, использование подобной практики позволит вам оперативно выявить реальные ошибки ваших тестов, то есть, если тест из разряда "passed after re-run", то при таких запусках 2-3 прогона подобные тесты отсеют.
При разработках тестов да, надо прогонять один сет как минимум 2 раза подряд.
M>В целом, ваше решение достаточно хорошее. У нас тут скоро планируется использовать селениум как раз в связке с .NET. Я думаю, выложенный вами материал будет интересен для ознакомления тем ребятам, которые на этом проекте будут работать.
Спасибо большое за фидбек! Из него я почерпнул пару вещей, которые обязательно добавлю в проект.
Все фигня кроме п4ел... П4елы впринципе тоже фигня, но их много.
Re[3]: Дизайн Selenium Web тестов для ASP.NET на C#
Здравствуйте, sLMoloch, Вы писали:
M>>Тут еще надо определиться с целевой аудиторией. У нас на одном из проектов тоже одной из целей дизайна была простота, легкость поддержки и чтения тестов. Для этих целей делалось расширение основного класса Selenium-клиента, когда в те же методы верификаций, типа isTextPresent, уже встявлялись assert-ы. И сами тестовые классы наследовались от этого расширенного клиента. То есть, разработчик тестов вполне мог использовать методы селениума, даже не догадываясь, откуда они вообще там доступны.
LM>Тут немного не понял, что имеется ввиду под целевой аудиторией?
Те люди, которые так или иначе будут ковырять код. В первую очередь, это, естественно, непосредственно разработчики тестов. Также, сюда можно включить мануальщиков, чтобы на начальных стадиях они могли хотя бы немного проревьюить код (насколько он соответствует требуемым действиям), а потом со временем, по мере возможностей, подключиться к автоматизации.
M>>И еще один момент. Как показала практика, для мануальщиков ООП весьма трудно для понимания. Гараздо проще именно процедурное программирование. В результате тест представляет собой последовательность команд вида:
M>>click( "some_locator" ); M>>isTextPresent( "Some text" ); M>>isElementPresent( "some_other_locator" );
M>>И так далее.
LM>Согласен на 100%. Поэтому для непрограммистов был разработан особой тип тестов — скриптовый, который пишется в любом текстовом редакторе. Например (Здесь файл):
LM>GoToLoginPage LM>EnterCredentials admin god LM>Login
LM>Заметьте что в скрипте не фигурирует никаких локаторов и аспектов работы с тем же AJAX — это не дело мануальщиков и бизнес людей.
Разумно. Но надо как-то это всё сгруппировать. Для больших систем будет слишком много команд, соответственно, в этой скриптовке потеряться можно будет запросто. Но это намного лучше, чем садить неподготовленного человека за IDE ковырять код.
M>>Идея оконных объектов достаточно удобна, мы ее тоже использовали. С той разницей, что в Java нет properties. Соответственно, пришлось использовать методы, причем они созвучны с методами Selenium-а, выполняющими основной ввод. То есть, все методы, которые делали клик начинались, с click, например clickOnSubmitButton(). По аналогии в соответствующих методах использовалиьсь префиксы type, select. Если бы в Java были properties, то ввод текста, выбор значения из списка точно были бы реализованы так же, как и у вас. M>>Причем, если то или иное действие приводило к загрузке другой страницы, то данный методы возвращали объект страницы. Соответственно, навигаторы, которые использовали вы, в данной задаче не использовались.
LM>Дело в том, что при кликах приходится выполнять очень много одинаковых действий, таких как LM>1) Ассерт того что мы заредиректались / не заредиректались на нужную страницу LM>2) Вывод "информативной ошибки" в случае редиректа на страницу с ASP.NET ошибкой LM>3) Ожидание AJAX
LM>Да и Page Objects по идее не должны заниматся ни чем кроме инкапсуляции доступа к элементам страницы (SRP), поэтому вся ответственность по переходам по страницам была переложена на навигатор.
Мы подобные вещи инкапсулировали в методах. Были отдельные классы, которые делали переходы и все необходимые верификации. На самом верхнем уровне это выглядело просто в виде вызова некоторого спец. метода, например
CommonView.viewHomePage();
Тут еще, возможно, загвоздка в том, что разработчик самого фреймфорка до этого работал с аналогичными системами, в которых использовался процедурный подход. Поэтому, его решение больше носило процедурный характер. Мне идея объектов-навигаторов тоже нравится, к тому же я её сам применял в своих решениях. Тут акцент немного на другом. По моим наблюдениям все эти ООП-шные штуки плохо доходят до тех, кто не так тесно связан с программированием.
LM>>>5) При ошибках тесты должны выдавать правильные ошибки, четко указывающие в чем проблема M>>Это скорее по части соглашений по написанию текста ошибок. Чем более детален текст описания, тем легче понять, что же произошло. Самый простой пример: если есть расхождения между ожидаемыми и фактическими результатами, то указываются оба: и что ожидали и что получили.
LM>Кроме этого, есть еще вещи, которые надо учесть. К примеру после логина мы проверяем что на домашней странице выводится имя залогиненного юзера. Но если мы не залогинились (свалилась процедура логина), то у нас будет Selenium ексепшен о том что элемент с именем "username" не найден. Что здесь в message для assert класть? Не понятно отчего этого элемента нет — кто то его просто удалил или процедура логина не прошла? а если не прошла — то из-за чего? LM>Поподробнее здесь
А нельзя ли просто сказать, что не получилось залогиниться? Если вам хочется больше деталей, то можно для каждой отдельной проверки своё сообщение написать. Например, при логине вы ожидаете, что появится страница с определенным заголовком, а также юзер отображается.
Соответственно, у вас будет 2 верификации и в случае ошибки будет 2 возможных сообщения об ошибке. Что-то типа:
"Problems while log into the application: Unexpected page is opened. Expected title <expected page title> but actual <actual page title>"
"Problems while log into the application: Can't find the logged user name on the page. Are you sure you're logged in?"
LM>>>6) Генерация кода, чтобы уменьшить количество работы M>>О да. Генерация — это всегда круто. Но в примерах, на которые вы ссылаетесь по данному пункту, вы используете исключительно xpath. На практике подобные локаторы одни из самых вредных, так как и работают медленней, а также более чувствительны к изменениям UI, особенно если захватывается несколько элементов в DOM-структуре.
LM>Никто не мешает использовать ID в параметрах к кодогенератору, это же только пример. XPath там используется только ради удобства. Мы заметили что очень много времени уходит на поиск добавившихся/изменившихся контролов в странице, и вписывание их в Page Object. В данном проекте просто открываешь страницу в FF, находишь все инпуты по паттерну "//input" , кидаешь результат в кодогенератор и вуаля — у тебя уже готовый Page Object. Если что-то изменилось на странице, то ошибки компиляции позволяют с легкостью найти все проблемные места.
Это хорошо работает если используемые элементы только инпуты. Если надо еще использовать ссылки, рисунки (ряд кнопок реализованы в виде рисунков со ссылками), select-ы, то тут нужна гибкость. Но это детали, которые вы и без меня прекрасно знаете. В принципе, такую часть хоть частично автоматизировать — это уже хороший плюс.
LM>Плюс к тому без Xpath никак не обратишься к тексту в любой строке внутри грида(
Да, есть случаи ,когда XPath — это единственное, чем можно достать нужный элемент. Но опять же, злоупотреблять им нежелательно.
LM>А насчет скорости работы — это довольно спорный вопрос, я по крайней мере спада в перформансе не заметил.
Вы пробовали тесты запускать под IE? Проблема в том, что при работе с IE используются JScript-овые библиотеки по работе с XPath, которые не отличаются высокой производительностью. Это одна из известных проблем. Поэтому зачастую рекомендуют использовать css-локаторы как альтернативу XPath. Под FF подобных проблем нет, но если речь идет о различных браузерах, то этот нюанс надо всегда помнить.
Да, также элементы по XPath могут не ловиться селениумом, если у них большая вложенность. Пару раз наталкивался на такое, когда элемент на странице есть, но по XPath он не находится.
LM>>>7) Должна быть возможность написания тестов непрограммистами
M>>Я об этом упомянул выше. "Непрограммисты" зачастую с трудом воспринимают ООП. Процедурный вызов попроще. Это исходя из моих личных наблюдений. Поэтому, либо поменьше наворотов, либо их заправить так, чтоб "непрограммист" и близко не видел, откуда что берется, а просто знал, что можно выбрать.
LM>Согласен. Тут есть маленькая проблема со скриптом выше — надо знать что туда писать — то есть как минимум иметь систему справки о доступных из данного состояния переходах, а в идеале тулзу, которая позволяет собирать тесты как конструктор лего) К счастью инфу для создания одного и другого легко выделить из описания Flow классов, и является делом времени и техники.
Рекомендую выработать определенный набор правил именования команд по выполняемым функциям. Также надобавлять тегов и т.п., после чего сформировать некое подобие "словаря", в котором структурированно это всё разместить. Тогда поиск нужных команд будет вестись по четко заданному алгоритму.
LM>>>8) Уменьшение времени тестирования путем запуска тестов в параллельных потоках, и используя Selenium Grid
M>>Кстати, есть еще и т.н. практика "чёртового колеса", когда тесты выполняются постоянно в бесконечном цикле. Средства автосборки подобное обеспечивают. Главное — создать 2 идентичные таски, каждая из которых запускает тесты и выдает нотификации. При этом как только заканчивается выполнение первой таски, то начинается вторая. А когда закончится вторая, то начинается первая.
LM>Мне почему то кажется что это просто пустая трата ресурсов — запускать по нескольку раз один сет тестов на одну ревизию кода. Если предполагается что тесты могут сработать по разному на одном и том же срезе кода, то что-то не в порядке с тестами — и эту проблему надо срочно решать, так как такие результаты не будут приниматся всерьез программистами. Типа — ну свалилось и хрен с ним, на следующий запуск глядишь сработают.
Вот именно, что когда несколько запусков подряд что-то стабильно валится, то уже имеет смысл смотреть, что же случилось. Во-первых, это должно быть нужно автоматизаторам, так как решение надо поддерживать. Более того, они же постоянно добавляют новые тесты. А так у них есть возможность наиболее оперативно узнавать, не повредили ли новые тесты старым. Более того, если эту инфраструктуру развернуть на отдельной машине, то это будет независимая экспертиза. Избавляемся от синдрома "works on my machine"
M>>В чем преимущество: тесты работают 24 часа в сутки 7 дней в неделю. Человек работает 8 часов 5 дней в неделю. Даже если учесть, что автотесты работают в том же темпе, что и выполняются вручную, то от такой разницы по времени мы получаем выигрыш ( 24 * 7 )/( 8 * 5 ) = 21/5 = 4.2
M>>То есть, работа одной машины заменяет работу 4-х людей. Особенно хорошо это себя проявит, когда суммарное время выполнения тестов будет исчисляться неделями.
LM>Работу машины нельзя никоим образом сравнивать с работой реальных людей — только потому что машина проверит тока то что предписано, но не заметит что потек где-то дизайн, половину контролов не видно. Да и невозможно на 100% автоматизировать все функциональные тесты.
Во-первых, я ничего не говорил о том, что всё можно автоматизировать на 100%. Как человек, который работает в данной области, я прекрасно понимаю, что это не столько даже невозможно, сколько не нужно. Тут речь о другом. Машина делает то, что при её отсутствии должны были бы делать люди. То есть самую рутину можно скинуть на машину. А тот показатель, что я привел, показывает, что у машины пропускная способность может быть в 4 раза выше человеческой только за счет того, что она может работать постоянно. Это только одно улучшение, которое уже сразу дает выигрыш. Почему бы им не воспользоваться? В полной мере этим можно насладиться, когда суммарное время выполнения автотестов будет составлять от нескольких суток и более.
M>>Помимо этого, использование подобной практики позволит вам оперативно выявить реальные ошибки ваших тестов, то есть, если тест из разряда "passed after re-run", то при таких запусках 2-3 прогона подобные тесты отсеют.
LM>При разработках тестов да, надо прогонять один сет как минимум 2 раза подряд.
Регрессия бегает минимум раз на релиз (по-хорошему). Но не забывайте, что старые тесты могут через некоторое время работать плохо. Причем, наверняка, сразу на это никто внимания не обратит. К чему это со временем приведет? Это приведет к тому, что в тестах будет куча мелких ошибок, на которые будут закрывать глаза и со временем их станет всё больше и больше. Это типичный сценарий загнивания проекта по автоматизации тестирования. Поэтому, чем оперативней получаемая информация, тем лучше это всё дело контролировать, отслеживать новые проблемы.
Не забывайте, что во-первых, новые тесты добавляются регулярно, а каждый новый тест — это источник новых проблем. Во-вторых, тестируемое приложение может меняться тоже достаточно часто, пусть по мелочи, но так или иначе что-то да прострельнет в виде свалившегося теста. Чем быстрее реакция на всё это "безобразие", тем меньше левых проблем накапливается.
И не забывайте, что по мере роста количества тестов, растет время их выполнения. Соответственно, когда время выполнения переваливает за 30 часов (даже с распараллеливанием), то стартовать вручную может оказаться неудобно. Почему бы такую рутину не автоматизировать?
Re[4]: Дизайн Selenium Web тестов для ASP.NET на C#
* В цитатах вырезаю те ветки, обсуждение которых считаю законченным.
M>Здравствуйте, sLMoloch, Вы писали:
M>Те люди, которые так или иначе будут ковырять код. В первую очередь, это, естественно, непосредственно разработчики тестов. Также, сюда можно включить мануальщиков, чтобы на начальных стадиях они могли хотя бы немного проревьюить код (насколько он соответствует требуемым действиям), а потом со временем, по мере возможностей, подключиться к автоматизации.
Гуд, включу в описание.
LM>>>>5) При ошибках тесты должны выдавать правильные ошибки, четко указывающие в чем проблема M>>>Это скорее по части соглашений по написанию текста ошибок. Чем более детален текст описания, тем легче понять, что же произошло. Самый простой пример: если есть расхождения между ожидаемыми и фактическими результатами, то указываются оба: и что ожидали и что получили.
LM>>Кроме этого, есть еще вещи, которые надо учесть. К примеру после логина мы проверяем что на домашней странице выводится имя залогиненного юзера. Но если мы не залогинились (свалилась процедура логина), то у нас будет Selenium ексепшен о том что элемент с именем "username" не найден. Что здесь в message для assert класть? Не понятно отчего этого элемента нет — кто то его просто удалил или процедура логина не прошла? а если не прошла — то из-за чего? LM>>Поподробнее здесь
M>А нельзя ли просто сказать, что не получилось залогиниться? Если вам хочется больше деталей, то можно для каждой отдельной проверки своё сообщение написать. Например, при логине вы ожидаете, что появится страница с определенным заголовком, а также юзер отображается.
M>Соответственно, у вас будет 2 верификации и в случае ошибки будет 2 возможных сообщения об ошибке. Что-то типа:
M>"Problems while log into the application: Unexpected page is opened. Expected title <expected page title> but actual <actual page title>" M>"Problems while log into the application: Can't find the logged user name on the page. Are you sure you're logged in?"
Точно, это было одной из целей проекта — показать как делать такого рода верификации. Ну и пара хороших практик, такая как считывание стак трейса с еррор пейджи и вывод его в мессадж ошибка теста. Очень удобно, и иногда с первого взгляда помогает разобратся в чем дело.
LM>>>>6) Генерация кода, чтобы уменьшить количество работы M>>>О да. Генерация — это всегда круто. Но в примерах, на которые вы ссылаетесь по данному пункту, вы используете исключительно xpath. На практике подобные локаторы одни из самых вредных, так как и работают медленней, а также более чувствительны к изменениям UI, особенно если захватывается несколько элементов в DOM-структуре.
LM>>Никто не мешает использовать ID в параметрах к кодогенератору, это же только пример. XPath там используется только ради удобства. Мы заметили что очень много времени уходит на поиск добавившихся/изменившихся контролов в странице, и вписывание их в Page Object. В данном проекте просто открываешь страницу в FF, находишь все инпуты по паттерну "//input" , кидаешь результат в кодогенератор и вуаля — у тебя уже готовый Page Object. Если что-то изменилось на странице, то ошибки компиляции позволяют с легкостью найти все проблемные места.
M>Это хорошо работает если используемые элементы только инпуты. Если надо еще использовать ссылки, рисунки (ряд кнопок реализованы в виде рисунков со ссылками), select-ы, то тут нужна гибкость. Но это детали, которые вы и без меня прекрасно знаете. В принципе, такую часть хоть частично автоматизировать — это уже хороший плюс.
"//a | //img" но потом, конечно приходится выбирать нужное из кучи мусора.
LM>>А насчет скорости работы — это довольно спорный вопрос, я по крайней мере спада в перформансе не заметил.
M>Вы пробовали тесты запускать под IE? Проблема в том, что при работе с IE используются JScript-овые библиотеки по работе с XPath, которые не отличаются высокой производительностью. Это одна из известных проблем. Поэтому зачастую рекомендуют использовать css-локаторы как альтернативу XPath. Под FF подобных проблем нет, но если речь идет о различных браузерах, то этот нюанс надо всегда помнить.
Хороший поинт. Под IE не пускал ниразу, каюсь. Причина — тесты в основном на функциональность и поведения в различных браузерах особо не касаются... Хотя, наверное это было бы полезно все тесты прогонять под каждый браузер.
LM>>>>8) Уменьшение времени тестирования путем запуска тестов в параллельных потоках, и используя Selenium Grid
M>>>Кстати, есть еще и т.н. практика "чёртового колеса", когда тесты выполняются постоянно в бесконечном цикле. Средства автосборки подобное обеспечивают. Главное — создать 2 идентичные таски, каждая из которых запускает тесты и выдает нотификации. При этом как только заканчивается выполнение первой таски, то начинается вторая. А когда закончится вторая, то начинается первая.
LM>>Мне почему то кажется что это просто пустая трата ресурсов — запускать по нескольку раз один сет тестов на одну ревизию кода. Если предполагается что тесты могут сработать по разному на одном и том же срезе кода, то что-то не в порядке с тестами — и эту проблему надо срочно решать, так как такие результаты не будут приниматся всерьез программистами. Типа — ну свалилось и хрен с ним, на следующий запуск глядишь сработают.
M>Вот именно, что когда несколько запусков подряд что-то стабильно валится, то уже имеет смысл смотреть, что же случилось. Во-первых, это должно быть нужно автоматизаторам, так как решение надо поддерживать. Более того, они же постоянно добавляют новые тесты. А так у них есть возможность наиболее оперативно узнавать, не повредили ли новые тесты старым. Более того, если эту инфраструктуру развернуть на отдельной машине, то это будет независимая экспертиза. Избавляемся от синдрома "works on my machine"
Да, конечно на отдельной машине, и на определенном срезе кода, без вариантов. Но я все же уверен в том что в основной транк Erratic Tests попадать не должны. Конечно это недостижимая иддилия, но стремится все равно надо.
M>>>Помимо этого, использование подобной практики позволит вам оперативно выявить реальные ошибки ваших тестов, то есть, если тест из разряда "passed after re-run", то при таких запусках 2-3 прогона подобные тесты отсеют.
LM>>При разработках тестов да, надо прогонять один сет как минимум 2 раза подряд.
M>Регрессия бегает минимум раз на релиз (по-хорошему). Но не забывайте, что старые тесты могут через некоторое время работать плохо. Причем, наверняка, сразу на это никто внимания не обратит. К чему это со временем приведет? Это приведет к тому, что в тестах будет куча мелких ошибок, на которые будут закрывать глаза и со временем их станет всё больше и больше. Это типичный сценарий загнивания проекта по автоматизации тестирования. Поэтому, чем оперативней получаемая информация, тем лучше это всё дело контролировать, отслеживать новые проблемы.
M>Не забывайте, что во-первых, новые тесты добавляются регулярно, а каждый новый тест — это источник новых проблем. Во-вторых, тестируемое приложение может меняться тоже достаточно часто, пусть по мелочи, но так или иначе что-то да прострельнет в виде свалившегося теста. Чем быстрее реакция на всё это "безобразие", тем меньше левых проблем накапливается.
M>И не забывайте, что по мере роста количества тестов, растет время их выполнения. Соответственно, когда время выполнения переваливает за 30 часов (даже с распараллеливанием), то стартовать вручную может оказаться неудобно. Почему бы такую рутину не автоматизировать?
Автоматизировать однозначно надо — без вариантов — это один из следующих топиков, которые я бы хотел покрыть. Быстрая реакция на изменения достигается тем, что смок тест запускается после каждого коммита (я надеюсь держать его в пределах 10 минут с помощью Grid) — в случае провала смок теста за поднятие билда ответсвеннен именно тот кто закомитался, и "ночных" тестов — прогоняются все тесты каждую ночь — за этот билд отвечает человек, который проводит ревью кода — ему легче всего разобратся и повлиять на то что тест будет пофиксан.
"Устаревание" тестов — это одна из самых больших проблем тестирования через UI, и именно на ее решение направлены методики ускорения тестов (быстрый фидбек и возможность починить пока ты еще "в теме"), читабельности тестов (быстрее понять и пофиксать), абстракции в псевдоязыке (бизнес правила, написаны на бизнес языке, азначит меняются только тогда когда меняется бизнес)
Гуд поинт — надо добавить "маппинг" проблем на цели проекта — то есть как проект решает определенные проблемы.
Все фигня кроме п4ел... П4елы впринципе тоже фигня, но их много.
Re[5]: Дизайн Selenium Web тестов для ASP.NET на C#
Здравствуйте, sLMoloch, Вы писали:
LM>* В цитатах вырезаю те ветки, обсуждение которых считаю законченным.
Аналогично
M>>А нельзя ли просто сказать, что не получилось залогиниться? Если вам хочется больше деталей, то можно для каждой отдельной проверки своё сообщение написать. Например, при логине вы ожидаете, что появится страница с определенным заголовком, а также юзер отображается.
M>>Соответственно, у вас будет 2 верификации и в случае ошибки будет 2 возможных сообщения об ошибке. Что-то типа:
M>>"Problems while log into the application: Unexpected page is opened. Expected title <expected page title> but actual <actual page title>" M>>"Problems while log into the application: Can't find the logged user name on the page. Are you sure you're logged in?"
LM>Точно, это было одной из целей проекта — показать как делать такого рода верификации. Ну и пара хороших практик, такая как считывание стак трейса с еррор пейджи и вывод его в мессадж ошибка теста. Очень удобно, и иногда с первого взгляда помогает разобратся в чем дело.
Добавьте к этому возможность делать screenshot в случае возникновения ошибки. Да и вообще, уделить внимание логгированию. Для этого уже есть достаточно много решений. Мне, правда, по работе приходилось иметь дело с решениями для Java и Ruby. Но, думаю, что-то .NET-ское можно нарыть.
LM>>>А насчет скорости работы — это довольно спорный вопрос, я по крайней мере спада в перформансе не заметил. M>>Вы пробовали тесты запускать под IE? Проблема в том, что при работе с IE используются JScript-овые библиотеки по работе с XPath, которые не отличаются высокой производительностью. Это одна из известных проблем. Поэтому зачастую рекомендуют использовать css-локаторы как альтернативу XPath. Под FF подобных проблем нет, но если речь идет о различных браузерах, то этот нюанс надо всегда помнить.
LM>Хороший поинт. Под IE не пускал ниразу, каюсь. Причина — тесты в основном на функциональность и поведения в различных браузерах особо не касаются... Хотя, наверное это было бы полезно все тесты прогонять под каждый браузер.
В принципе, если задача проверить работоспособность функционала, то да, лучше ограничиться FF, как минимум потому, что в нем меньше ограничений для работы с Селениумом (например, возможность ввода в input type=file, настраиваемая загрузка файлов без появления диалога сохранения и т.п.).
Но все-таки на другие браузеры надо поглядывать просто потому, что FF пользуется не большинство потенциальных пользователей. Как вариант, можно набрать некоторое количество сертификационных тестов (те же смоки) и пускать их под разными браузерами.
LM>>>Мне почему то кажется что это просто пустая трата ресурсов — запускать по нескольку раз один сет тестов на одну ревизию кода. Если предполагается что тесты могут сработать по разному на одном и том же срезе кода, то что-то не в порядке с тестами — и эту проблему надо срочно решать, так как такие результаты не будут приниматся всерьез программистами. Типа — ну свалилось и хрен с ним, на следующий запуск глядишь сработают.
M>>Вот именно, что когда несколько запусков подряд что-то стабильно валится, то уже имеет смысл смотреть, что же случилось. Во-первых, это должно быть нужно автоматизаторам, так как решение надо поддерживать. Более того, они же постоянно добавляют новые тесты. А так у них есть возможность наиболее оперативно узнавать, не повредили ли новые тесты старым. Более того, если эту инфраструктуру развернуть на отдельной машине, то это будет независимая экспертиза. Избавляемся от синдрома "works on my machine"
LM>Да, конечно на отдельной машине, и на определенном срезе кода, без вариантов. Но я все же уверен в том что в основной транк Erratic Tests попадать не должны. Конечно это недостижимая иддилия, но стремится все равно надо.
Дык, никто же не говорит, что попадать не должны. Суть в том, что нужно выявлять нестабильные тесты регулярно и так же регулярно это дело корректировать. В этом весь прикол постоянных запусков. Вы постоянно контролируете работоспособность тестов и чистоту получаемой информации. Это одна из ключевых задач автоматизаторов — поддерживать своё решение в рабочем состоянии.
M>>>>Помимо этого, использование подобной практики позволит вам оперативно выявить реальные ошибки ваших тестов, то есть, если тест из разряда "passed after re-run", то при таких запусках 2-3 прогона подобные тесты отсеют.
LM>>>При разработках тестов да, надо прогонять один сет как минимум 2 раза подряд.
M>>Регрессия бегает минимум раз на релиз (по-хорошему). Но не забывайте, что старые тесты могут через некоторое время работать плохо. Причем, наверняка, сразу на это никто внимания не обратит. К чему это со временем приведет? Это приведет к тому, что в тестах будет куча мелких ошибок, на которые будут закрывать глаза и со временем их станет всё больше и больше. Это типичный сценарий загнивания проекта по автоматизации тестирования. Поэтому, чем оперативней получаемая информация, тем лучше это всё дело контролировать, отслеживать новые проблемы.
M>>Не забывайте, что во-первых, новые тесты добавляются регулярно, а каждый новый тест — это источник новых проблем. Во-вторых, тестируемое приложение может меняться тоже достаточно часто, пусть по мелочи, но так или иначе что-то да прострельнет в виде свалившегося теста. Чем быстрее реакция на всё это "безобразие", тем меньше левых проблем накапливается.
M>>И не забывайте, что по мере роста количества тестов, растет время их выполнения. Соответственно, когда время выполнения переваливает за 30 часов (даже с распараллеливанием), то стартовать вручную может оказаться неудобно. Почему бы такую рутину не автоматизировать?
LM>Автоматизировать однозначно надо — без вариантов — это один из следующих топиков, которые я бы хотел покрыть. Быстрая реакция на изменения достигается тем, что смок тест запускается после каждого коммита (я надеюсь держать его в пределах 10 минут с помощью Grid) — в случае провала смок теста за поднятие билда ответсвеннен именно тот кто закомитался, и "ночных" тестов — прогоняются все тесты каждую ночь — за этот билд отвечает человек, который проводит ревью кода — ему легче всего разобратся и повлиять на то что тест будет пофиксан.
Как по мне, с запуском тестов при каждом коммите — это слишком. Я бы ограничился проверкой, что решение собирается + ну, максимум сделал бы что-то типа dry-run, чтобы проверить, что тесты в принципе могут пакетом запускаться. У меня бывали случаи, когда всё нормально компилировалось, но в некоторых методах я где-то ошибся с аннотациями и вот когда дело доходило до запусков, то весь сет просто валился, так как тестовый движок тупо вылетал с исключением.
Так что, думаю, для реакции на коммит больше проверок делать не надо. Народ и к такому не сразу привыкает. Мне лично потребовалось достаточно много времени, чтобы вбить народу в бошку, что после коммита надо убедиться, что нужно дождаться нотификации об успешной сборке, а потом уже идти домой или еще с чем-то возиться, так как в команде много народу, а с кривой сборкой работать тяжело.
LM>"Устаревание" тестов — это одна из самых больших проблем тестирования через UI, и именно на ее решение направлены методики ускорения тестов (быстрый фидбек и возможность починить пока ты еще "в теме"), читабельности тестов (быстрее понять и пофиксать), абстракции в псевдоязыке (бизнес правила, написаны на бизнес языке, азначит меняются только тогда когда меняется бизнес)
Вот в том числе и для борьбы с устаревшими тестами направлена практика "чертового колеса", о которой я говорил.
LM>Гуд поинт — надо добавить "маппинг" проблем на цели проекта — то есть как проект решает определенные проблемы.
Кстати, вы удачно вспомнили про маппинг. Учитывая, что в UI тестировании объекты могут со временем менять локаторы, то имеет смысл примаппить локаторы к некоторому псевдониму, который реально в коде и используется. Мы, например, выносили локаторы в отдельные XML-файлы и если какой-то элемент поменялся, то нам надо было только в одном месте обновить локатор.
Re[6]: Дизайн Selenium Web тестов для ASP.NET на C#
M>Добавьте к этому возможность делать screenshot в случае возникновения ошибки. Да и вообще, уделить внимание логгированию. Для этого уже есть достаточно много решений. Мне, правда, по работе приходилось иметь дело с решениями для Java и Ruby. Но, думаю, что-то .NET-ское можно нарыть.
ссылками поделитесь? )
M>Как по мне, с запуском тестов при каждом коммите — это слишком. Я бы ограничился проверкой, что решение собирается + ну, максимум сделал бы что-то типа dry-run, чтобы проверить, что тесты в принципе могут пакетом запускаться. У меня бывали случаи, когда всё нормально компилировалось, но в некоторых методах я где-то ошибся с аннотациями и вот когда дело доходило до запусков, то весь сет просто валился, так как тестовый движок тупо вылетал с исключением.
M>Так что, думаю, для реакции на коммит больше проверок делать не надо. Народ и к такому не сразу привыкает. Мне лично потребовалось достаточно много времени, чтобы вбить народу в бошку, что после коммита надо убедиться, что нужно дождаться нотификации об успешной сборке, а потом уже идти домой или еще с чем-то возиться, так как в команде много народу, а с кривой сборкой работать тяжело.
У нас после каждого комита запускаюся все юнит тесты, к этому народ очень быстро привык. Не пускали UI тесты только из за экономии времени — сейчас с grid я думаю эту проблему решим.
M>Кстати, вы удачно вспомнили про маппинг. Учитывая, что в UI тестировании объекты могут со временем менять локаторы, то имеет смысл примаппить локаторы к некоторому псевдониму, который реально в коде и используется. Мы, например, выносили локаторы в отдельные XML-файлы и если какой-то элемент поменялся, то нам надо было только в одном месте обновить локатор.
Ну Page Object это по сути и есть маппинг локаторов на проперти.
Все фигня кроме п4ел... П4елы впринципе тоже фигня, но их много.
Re[7]: Дизайн Selenium Web тестов для ASP.NET на C#
M>>Добавьте к этому возможность делать screenshot в случае возникновения ошибки. Да и вообще, уделить внимание логгированию. Для этого уже есть достаточно много решений. Мне, правда, по работе приходилось иметь дело с решениями для Java и Ruby. Но, думаю, что-то .NET-ское можно нарыть.
LM>ссылками поделитесь? )
Как я уже говорил, я больше работал с Java и Ruby, поэтому и решения реализованы для них. Например, вот:
Я конкретно для .NET не искал, но сразу могу сказать, что в случае необходимости я бы первым делом копал в направлении репортинг-решений, привязанных к используемому тестовому движку. Например, сразу не глядя нашел:
А дальше, берем напильник в руки и рихтуем под свои нужды
M>>Как по мне, с запуском тестов при каждом коммите — это слишком. Я бы ограничился проверкой, что решение собирается + ну, максимум сделал бы что-то типа dry-run, чтобы проверить, что тесты в принципе могут пакетом запускаться. У меня бывали случаи, когда всё нормально компилировалось, но в некоторых методах я где-то ошибся с аннотациями и вот когда дело доходило до запусков, то весь сет просто валился, так как тестовый движок тупо вылетал с исключением.
M>>Так что, думаю, для реакции на коммит больше проверок делать не надо. Народ и к такому не сразу привыкает. Мне лично потребовалось достаточно много времени, чтобы вбить народу в бошку, что после коммита надо убедиться, что нужно дождаться нотификации об успешной сборке, а потом уже идти домой или еще с чем-то возиться, так как в команде много народу, а с кривой сборкой работать тяжело.
LM>У нас после каждого комита запускаюся все юнит тесты, к этому народ очень быстро привык. Не пускали UI тесты только из за экономии времени — сейчас с grid я думаю эту проблему решим.
А, запуск юнит-тестов — это да, вполне уместно. Вот насчет UI-тестов лучше так не делать. Я бы точно их не включал в триггер на коммит. Во-первых, они дольше выполняются, во-вторых, в них заметно больше ложных срабатываний (за счет того, что тестируемая система является внешней по отношению к тестам, в отличие от юнит тестов). Такие тесты лучше пускать отдельно и следить за результатами регулярно.
Не нужно автосборку после коммита делать слишком длительной. Например, если билд собирается 1-2 часа, то уже стоит задуматься, а может делать автосборку делать не по триггеру, а на ежедневной основе в нерабочее время по расписанию.
M>>Кстати, вы удачно вспомнили про маппинг. Учитывая, что в UI тестировании объекты могут со временем менять локаторы, то имеет смысл примаппить локаторы к некоторому псевдониму, который реально в коде и используется. Мы, например, выносили локаторы в отдельные XML-файлы и если какой-то элемент поменялся, то нам надо было только в одном месте обновить локатор.
LM>Ну Page Object это по сути и есть маппинг локаторов на проперти.
Только отчасти. Вы в проперти закинули основные операции. То есть в текстовое поле вы делаете только ввод данных, в выпадающем списке только выбор элемента + соответствующие действия по извлечению значений. Но спектр задач может быть пошире. Каждый элемент иногда желательно проверить на существование (причем зачастую это сделать крайне желательно, чтобы стабилизировать тесты), а также извлечь подсвеченным текст, в списках получить выбранные значения, все значения, выбрать всё или некоторую группу элементов, не говоря уже о нетривиальных задачах, как проверка расположения элементов, извлечения конкретных атрибутов элемента. Да, всё это легко оборачивается в проперти, но суть в том, что их будет несколько на один и тот же элемент. Это в свою очередь влечет за собой множественное использование одного и того же локатора. Соответственно, при изменениях в UI придется делать правки в нескольких местах. Наличие же карты элементов с сопоставленными псевдонимами, заменяющими локатор, приведет к тому, что при подобных изменениях в UI для каждого элемента нужно делать правку только в одном месте — в карте элементов, независимо от того, насколько элемент интенсивно используется.
