Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 28
Ох и огромная же статья получилась. Видно, что вы немало сил вложили в не.
Спасибо. было интересно. Вынес для себя довольно много полезных мыслей. Хотя, если честно, до конца меня не хватило :-)
Спасибо. было интересно. Вынес для себя довольно много полезных мыслей. Хотя, если честно, до конца меня не хватило :-)
Шатко-валко автоматизированное тестирование превращается из хипстерства в промышленный стандарт. Про тусидайдис: events.yandex.ru/events/yac/2012/talks/362/, если еще не видели.
Благодарю. Между прочим этот видео доклад меня впервые и познакомил с thucydides.
Думаю, наверное, в том же ключе. В любом случае, есть смысл рассматривать весь стэк автотестирования. А работа с Webdriver и Page Object' ами в этом стэке находится уж точно не на самом верху. Thucydides, как мне кажется, имеет много чего хорошего для поддержания этого стэка на верхних уровнях. Зато для разработки того, что будет выполнять всю грязную работу, простор огромный. И на этом уровне инструмент можно дополнять и совершенствовать. Но в меру, чтобы стэк не развалился)
Думаю, наверное, в том же ключе. В любом случае, есть смысл рассматривать весь стэк автотестирования. А работа с Webdriver и Page Object' ами в этом стэке находится уж точно не на самом верху. Thucydides, как мне кажется, имеет много чего хорошего для поддержания этого стэка на верхних уровнях. Зато для разработки того, что будет выполнять всю грязную работу, простор огромный. И на этом уровне инструмент можно дополнять и совершенствовать. Но в меру, чтобы стэк не развалился)
Не в обиду автору:
— очередная общая вода: 'Что такое функциональное тестирование + selenium?'
— очередной «Hello world + selenium»
— очередной «framework Hello world(WebDriver)»
— очень плохие картинки и мусорные скриншоты
— ненужные детали о версиях браузеров и прочих тонкостей
Вместо тысячи слов, лучше рассказать:
— сколько у вас кейсов/чеков (автоматизированно/всего)
— оценочный объем покрытия карты функциональности (или чего-то иного)
— время занимаемое для прогона всей выше сказанной регрессии и требуемые на это человеко-робото-ресуры
— статы по найденным/пропущенным багам
и описание как вы этого достигли
PS в случае делания поделиться нашими наработками над Webdriver линк на GitHub.
— очередная общая вода: 'Что такое функциональное тестирование + selenium?'
— очередной «Hello world + selenium»
— очередной «framework Hello world(WebDriver)»
— очень плохие картинки и мусорные скриншоты
— ненужные детали о версиях браузеров и прочих тонкостей
Вместо тысячи слов, лучше рассказать:
— сколько у вас кейсов/чеков (автоматизированно/всего)
— оценочный объем покрытия карты функциональности (или чего-то иного)
— время занимаемое для прогона всей выше сказанной регрессии и требуемые на это человеко-робото-ресуры
— статы по найденным/пропущенным багам
и описание как вы этого достигли
PS в случае делания поделиться нашими наработками над Webdriver линк на GitHub.
Спасибо за замечание.
Вы правы. Статья получилась большая. Хотел охватить как можно больше. Скрины… В оригинале они смотрятся лучше) Моя первая статья. Первый блин, как водится) Буду иметь ввиду. Ссылки, кстати есть!
А что касается регрессии, ресурсов и т. д… Чуть выше я написал ответ. Вам бы я ответил примерно так же.
Вы правы. Статья получилась большая. Хотел охватить как можно больше. Скрины… В оригинале они смотрятся лучше) Моя первая статья. Первый блин, как водится) Буду иметь ввиду. Ссылки, кстати есть!
А что касается регрессии, ресурсов и т. д… Чуть выше я написал ответ. Вам бы я ответил примерно так же.
[удалено]
PhantomJSDriver, кстати, довольно полезная вещь. При помощи этого, «браузера» можно прогонять тесты на минимальной ubuntu безо всяких гномов и других GUI-ев.
К своему стыду должен признатъся, что полностью статью не осилил.
Но по не совсем большому опыту UI-тестов и после долгих мучений с селениумом, остановились на selenide.org/. Супер полезная вещь. Гоняем каждую ночь около 130 тестов. Он хоть и является своего рода враппером селениума, но очень сильно облегчает написание понятных, коротких и четких тестов. Создатели кстати тоже присутствуют на хабре: asolntsev См. также видео на вимео: vimeo.com/60614493
Но по не совсем большому опыту UI-тестов и после долгих мучений с селениумом, остановились на selenide.org/. Супер полезная вещь. Гоняем каждую ночь около 130 тестов. Он хоть и является своего рода враппером селениума, но очень сильно облегчает написание понятных, коротких и четких тестов. Создатели кстати тоже присутствуют на хабре: asolntsev См. также видео на вимео: vimeo.com/60614493
Опачки, спасибо!
Это не лучше видео, лучше посмотреть вот это короткое (30 секунд, весело), либо это длинное (с конференции Selenium Camp 2013, серьёзно).
А так да, Selenide как раз задумана, чтобы проблемы с Ajax, таймаутами, StaleElementException, выбором браузера решались автоматически. Тут есть пример теста для Gmail — он почти так же труден для тестирования, как и Google Drive. Благодаря тому, что Selenide полностью прячет работу с WebDriver, делить код на PageObjects, а их в свою очередь на блоки, фреймы или какие угодно куски становится максимально просто.
Автору спасибо за статью!
Своим опытом нужно делиться, с чужого опыта нужно учиться. Курс правильный!
Это не лучше видео, лучше посмотреть вот это короткое (30 секунд, весело), либо это длинное (с конференции Selenium Camp 2013, серьёзно).
А так да, Selenide как раз задумана, чтобы проблемы с Ajax, таймаутами, StaleElementException, выбором браузера решались автоматически. Тут есть пример теста для Gmail — он почти так же труден для тестирования, как и Google Drive. Благодаря тому, что Selenide полностью прячет работу с WebDriver, делить код на PageObjects, а их в свою очередь на блоки, фреймы или какие угодно куски становится максимально просто.
Автору спасибо за статью!
Своим опытом нужно делиться, с чужого опыта нужно учиться. Курс правильный!
Длинновато, но в полне увлекательно. Согласен с комментарием allexx.
Да, это не статья, а целая одностраничная книга. И должен признать, что таки довольно достойная книга :D
А вы меня по одному пункту таки опередили.
Я вот тоже пытался решить задачу с автоматическим переключением фреймов. И тоже через AOP. Но, я пошел по пути отлова обращения к каждому задекларированному элементу (на C# для декларации используются свойства, аналоги гетеров/сетеров на Java).
В итоге у меня ничего не получилось, я запутался и это дело забросил.
А сейчас, благодаря вашей статье понял, что отлавливать нужно было не обращение к элементам, а обращения к методам Пейджобжекта, которые реализовывали действие.
А вы меня по одному пункту таки опередили.
Я вот тоже пытался решить задачу с автоматическим переключением фреймов. И тоже через AOP. Но, я пошел по пути отлова обращения к каждому задекларированному элементу (на C# для декларации используются свойства, аналоги гетеров/сетеров на Java).
В итоге у меня ничего не получилось, я запутался и это дело забросил.
А сейчас, благодаря вашей статье понял, что отлавливать нужно было не обращение к элементам, а обращения к методам Пейджобжекта, которые реализовывали действие.
Я рад, что статья в чем-то помогла.
На самом деле я тоже до этого не сразу дошел.
Первое время я экспериментировал на вэб-клиенте 1С. А он нашпигован iframe'ами и при определенной настройке все открывает в новых окнах браузера. И работать с такими Page Object'ами было крайне неудобно из-за необходимости постоянно переключать драйвер. Решение созрело в тот момент, когда в голове выстроилась такая цепочка:
driver.switchTo.window(somehandle);
driver.switchTo.frame(someWebElement);
driver.switchTo.frame(anotherWebElement);
Получается что-то вроде пути, который нужно пройти перед выполнением метода. А дальше осталось только посмотреть в сторону АОП.
На самом деле я тоже до этого не сразу дошел.
Первое время я экспериментировал на вэб-клиенте 1С. А он нашпигован iframe'ами и при определенной настройке все открывает в новых окнах браузера. И работать с такими Page Object'ами было крайне неудобно из-за необходимости постоянно переключать драйвер. Решение созрело в тот момент, когда в голове выстроилась такая цепочка:
driver.switchTo.window(somehandle);
driver.switchTo.frame(someWebElement);
driver.switchTo.frame(anotherWebElement);
Получается что-то вроде пути, который нужно пройти перед выполнением метода. А дальше осталось только посмотреть в сторону АОП.
На самом деле тестирование почти никому нафиг не нужно ))
Все эти селениумы с phantomjs/etc ежедневно используются для фетчинка и парсинга миллионов страниц чужих сайтов (типа выдачи яндекса, гугла и проч)
Все эти селениумы с phantomjs/etc ежедневно используются для фетчинка и парсинга миллионов страниц чужих сайтов (типа выдачи яндекса, гугла и проч)
Вы таки не поверите, но вы таки правы.
Если взять первые строки с сайта проекта Selenium, то они будут следующими:
Так что, использовать Selenium для фетчинга и парсинга страниц – не выходит за рамки использования инструмента.
Другое дело, что работа Selenium может быть сравнительно медленной. В таком случае, можно воспользоваться библиотеками Mechanize для:
Или собрать свою на C#
Если взять первые строки с сайта проекта Selenium, то они будут следующими:
What is Selenium?
Selenium automates browsers. That's it. What you do with that power is entirely up to you. Primarily it is for automating web applications for testing purposes, but is certainly not limited to just that. Boring web-based administration tasks can (and should!) also be automated as well.
Так что, использовать Selenium для фетчинга и парсинга страниц – не выходит за рамки использования инструмента.
Другое дело, что работа Selenium может быть сравнительно медленной. В таком случае, можно воспользоваться библиотеками Mechanize для:
Или собрать свою на C#
Спасибо за оставленные комментарии. Получилось больше, чем я ожидал)
Сам бы я мог сказать вот что…
Понятно, что описанные наработки, впринципе, так и могут остаться наработками, так как все выше описанное делалось в свободное время. А какого-то серьезного проекта, на котором можно все это закрутить покрепче, пока к меня нет. Но, в любом случае, опыт оказался полезным.
Жду новых!
Сам бы я мог сказать вот что…
Понятно, что описанные наработки, впринципе, так и могут остаться наработками, так как все выше описанное делалось в свободное время. А какого-то серьезного проекта, на котором можно все это закрутить покрепче, пока к меня нет. Но, в любом случае, опыт оказался полезным.
Жду новых!
В своем заключении я как-то расплывчато описал предполагаемый конечный результат. Он бы наверное был таким…
Получился бы набор wrapper'ов для Webdriver'a. Каждый выполняет определенную функцию:
— управление браузерными окнами;
— выполнение действий над одним окном;
— обвертки, которые скрывают драйвер и сразу позволяют использовать интерфейсы HasInputDevises, Options, JavascriptExecutor и т. д. (очень полезные интерфейсы, кстати).
Все это бы являлось фундаментом для шаблонов, которые позволили бы строить модели сервисов или отдельных страниц. Причем, внутри этих моделей можно было бы использовать инструменты фрэймворков yandex qa tools (для Google Drive у меня это получилось), thucydides или Selenide (захотелось попробовать) + набор описанных выше инструментов.
Но, я думаю, такая модель избыточна для тестирования большинства вэб-приложений. Скорее она бы больше подошла для чего-то такого сложного, сравнимого с вэб-клиентом 1С или Google Drive.
Получился бы набор wrapper'ов для Webdriver'a. Каждый выполняет определенную функцию:
— управление браузерными окнами;
— выполнение действий над одним окном;
— обвертки, которые скрывают драйвер и сразу позволяют использовать интерфейсы HasInputDevises, Options, JavascriptExecutor и т. д. (очень полезные интерфейсы, кстати).
Все это бы являлось фундаментом для шаблонов, которые позволили бы строить модели сервисов или отдельных страниц. Причем, внутри этих моделей можно было бы использовать инструменты фрэймворков yandex qa tools (для Google Drive у меня это получилось), thucydides или Selenide (захотелось попробовать) + набор описанных выше инструментов.
Но, я думаю, такая модель избыточна для тестирования большинства вэб-приложений. Скорее она бы больше подошла для чего-то такого сложного, сравнимого с вэб-клиентом 1С или Google Drive.
Прочитал вашу статью, укрепился в своем мнении о подходах к тестированию Selenium:
— У вас многостраничный сайт с простым взаимодействием? Не парьтесь, записывайте тесты средствами Selenium прямо в браузере. Проще перетцкать 5 ссылок и проверить что в DIV-е c определенным CSS классом есть нужный текст, чем цеплять PageObject и писать враппер. Даже если тест перестанет быть актуальным, все равно его проще перезаписать.
— У вас многостраничный сайт со сложным взаимодействием, кучей ajax? Делайте PageObject, используйте готовые каркасы, делайте обертки доступа. В общем весь тот смак, что у вас в статье. Только не думаю что это осилит обычный тестировщик. Тут надо запрягать программиста, разбирающегося в вашем View. Некоторые кодовые концепции, мягко говоря, стоят программиста от 100 000 в месяц. Высококлассного разработчика иногда жалко кидать на тестирование, но без столь серьезного подхода имхо автоматизировать тестирование таких штук не выйдет.
— У вас одностраничное сложное интернет приложение (RIA), с кучей AJAX и JavaScript. Да у вас HTML в исходниках меньше, чем JavaScript. Тут PageObject уже не пойдет, т.к. это автоматически GodObject будет. Надо писать сложную обертку для тестов, отталкиваясь от модели вашего приложения (а не того, что там можно на странице сделать или увидеть). Т.е. не уметь тыкать по DOM элементам, а уметь оперировать абстракциями системы (кнопки, операции, таблицы, формы, рабочие столы, деревья навигации и т.п.). Это тоже целое море, но архитектурно с PageObject общего ничего не имеет (у меня такой вариант получился).
Боже мой, MethodInterceptor в интеграционном тестировании… Куда катится этот мир, где те милые тестерши, которые с круглыми глазами приходят к тебе и говорят «Ой, я кажется багу нашла! Но не уверена :\ Ты не мог бы посмотреть». А ты такой подходишь, смотришь, жмакаешь F12, пишешь пару волшебных строчек, и оно снова работает. И на тебя смотрят то ли как на колдуна темного, то ли как на героя… Ушли времена, совсем ушли…
Кстати, а вы как-то параллелите запуск тестов на билд сервере? С этим обычно сложности бывают в плане организации технической части.
— У вас многостраничный сайт с простым взаимодействием? Не парьтесь, записывайте тесты средствами Selenium прямо в браузере. Проще перетцкать 5 ссылок и проверить что в DIV-е c определенным CSS классом есть нужный текст, чем цеплять PageObject и писать враппер. Даже если тест перестанет быть актуальным, все равно его проще перезаписать.
— У вас многостраничный сайт со сложным взаимодействием, кучей ajax? Делайте PageObject, используйте готовые каркасы, делайте обертки доступа. В общем весь тот смак, что у вас в статье. Только не думаю что это осилит обычный тестировщик. Тут надо запрягать программиста, разбирающегося в вашем View. Некоторые кодовые концепции, мягко говоря, стоят программиста от 100 000 в месяц. Высококлассного разработчика иногда жалко кидать на тестирование, но без столь серьезного подхода имхо автоматизировать тестирование таких штук не выйдет.
— У вас одностраничное сложное интернет приложение (RIA), с кучей AJAX и JavaScript. Да у вас HTML в исходниках меньше, чем JavaScript. Тут PageObject уже не пойдет, т.к. это автоматически GodObject будет. Надо писать сложную обертку для тестов, отталкиваясь от модели вашего приложения (а не того, что там можно на странице сделать или увидеть). Т.е. не уметь тыкать по DOM элементам, а уметь оперировать абстракциями системы (кнопки, операции, таблицы, формы, рабочие столы, деревья навигации и т.п.). Это тоже целое море, но архитектурно с PageObject общего ничего не имеет (у меня такой вариант получился).
Боже мой, MethodInterceptor в интеграционном тестировании… Куда катится этот мир, где те милые тестерши, которые с круглыми глазами приходят к тебе и говорят «Ой, я кажется багу нашла! Но не уверена :\ Ты не мог бы посмотреть». А ты такой подходишь, смотришь, жмакаешь F12, пишешь пару волшебных строчек, и оно снова работает. И на тебя смотрят то ли как на колдуна темного, то ли как на героя… Ушли времена, совсем ушли…
Кстати, а вы как-то параллелите запуск тестов на билд сервере? С этим обычно сложности бывают в плане организации технической части.
По поводу первого пункта — наверное об этом я и говорил в своем комментарии выше.
Второй — никаких комментариев. Все уже сказано)
А вот третий пункт я не рассматривал. Нужно будет посмотреть, просто ради самообразования. Но, м.б. это действительно граница применения Page Object.
Да. Некоторые тестировщики сейчас могут подойти и пальцем показать, в какой строчке кода баг, и заставить фиксить))))
Что касается распараллеливания… Тут у меня есть некоторые пробелы. На моем текущем проекте используется TestComplete, который в принципе не поддерживает параллельный запуск — если только разбивать проект на части и запускать на разных машинах. Так что проблемы в теоретических и практических пробелах.
Пока я выполнял описанную в статье работу, то копнул и в эту сторону. Скажем — просто параллельные запуски тестов используя средства и настройки TestNG у меня получались без проблем, в том числе и на удаленных машинах. Но до использования каких-то build или continous integration серверов (надеюсь, я правильно понял вопрос) типа jenkins дело пока не дошло. А для экспериментальных целей мне пока хватило того, что получилось.
Но, эти пробелы, надеюсь, скоро закроются)
Второй — никаких комментариев. Все уже сказано)
А вот третий пункт я не рассматривал. Нужно будет посмотреть, просто ради самообразования. Но, м.б. это действительно граница применения Page Object.
Да. Некоторые тестировщики сейчас могут подойти и пальцем показать, в какой строчке кода баг, и заставить фиксить))))
Что касается распараллеливания… Тут у меня есть некоторые пробелы. На моем текущем проекте используется TestComplete, который в принципе не поддерживает параллельный запуск — если только разбивать проект на части и запускать на разных машинах. Так что проблемы в теоретических и практических пробелах.
Пока я выполнял описанную в статье работу, то копнул и в эту сторону. Скажем — просто параллельные запуски тестов используя средства и настройки TestNG у меня получались без проблем, в том числе и на удаленных машинах. Но до использования каких-то build или continous integration серверов (надеюсь, я правильно понял вопрос) типа jenkins дело пока не дошло. А для экспериментальных целей мне пока хватило того, что получилось.
Но, эти пробелы, надеюсь, скоро закроются)
Карьерный экскаватор завидует скорости вашего копания!
По поводу параллелизма, да, я имел ввиду системы непрерывной интеграции. У нас был TeamCity.
Если интересно ради самообразования, то у нас получилось что-то вроде этого: habrahabr.ru/post/181660/
Только последний месяц-два была сильная подвижка, код теперь выглядит так:
Соответственно в тесте мы оперируем такими терминами как Сущности (BaseInDocumentImpl, BaseInDocument), Действиями (это то, что воплощается в кнопки, прикладной код — Operations, CreateDocument), и собственно указывать лямбда выражениями над чем мы хотим работать в сущности (ForMember(la => la.SomeNewField).GetField(), SomeNewField — это поле типа сущности).
Вот примерно так пишут тест. Выходит что предметная область теста совпадает с предметной областью прикладного разработчика и аналитика. Они оперируют одними и теми же понятиями, и в принципе понимают тест, но могут даже не видеть интерфейс, который они тестируют.
Основной смысл тестов — убедиться что на крайней линии сложная цепочка действий выполняется без каких-либо отклонений. Фактически что можно провести тот или иной бизнес-процесс. Например провести определенный документ и получить нужные данные.
Конечно такие тесты не способны детализировать интерфейс, если есть такая потребность, то можно делать вставки голым Selenium или JavaScript. Но как показала практика — стабильные тесты таким образом простые разработчики написать не могут. Нужно понимать работу сложного интерфейса, крайне динамичного. Это сложно.
В общем как-то так оно вышло.
А вы исключительно тестированием занимаетесь? Просто то, что вы описали — это работа одного-двух человек в течении месяца, полутора. Интересно как в вашей организации процесс тестирования поставлен.
У нас API разрабатывал я, при этом я же занимался частью View (серверная и клиентская). Ещё 2 человека занимались бэкендом. Это ядро. Один человек ведет TeamCity. Есть ещё 10 прикладных разработчиков, которые пишут бизнес-логику. На разработку первой очереди API для тестов ушел где-то месяц. С тех пор он регулярно дорабатывался, в последний раз была введена более жесткая типизация (на это потребовалось дня 3). Сам Selenium живет уже год, написано 70+ тестов, они проходят где-то час в 2 потока. Интересное наблюдение — на поддержку тестов уходит больше времени, чем на написание API, развертывание и написание самих тестов. С одной стороны это говорит о не слишком высоком качестве API, с другой стороны это можно объяснить высокой динамикой интерфейса (написанного на ExtJS). Но если подумать, то без API покрыть Selenium тесты такую систему вообще было бы нереально, если даже API тяжело стабилизировать.
В последнее время 1 из 3 падений теста говорили о реальной проблеме в системе, ещё 1 говорило о несоответствии логики теста логике (возможно изменившейся) системы, а последнее случалось из-за проблем с самим API теста. Как-то так.
По поводу параллелизма, да, я имел ввиду системы непрерывной интеграции. У нас был TeamCity.
Если интересно ради самообразования, то у нас получилось что-то вроде этого: habrahabr.ru/post/181660/
Только последний месяц-два была сильная подвижка, код теперь выглядит так:
[Test]
public void DocumentOperationGridOperationTest()
{
var grid = Env.Navigation.OpenList<BaseInDocumentImpl>();
grid.Toolbar.Click(typeof(CreateDocument));
var docForm = Env.TabPanel.GetForm<BaseInDocumentImpl>();
docForm.finishOperation();
docForm.Close();
var grid = Env.Navigation.OpenList<BaseInDocument>();
grid.Data.First().Select();
grid.Toolbar.Click(typeof(Operations), typeof(CreateDocument));
var docForm = grid.OpenForm();
var fieldValue = docForm.ForMember(la => la.SomeNewField).GetField<TextField>();
Assert.False(string.IsNullOrEmpty(fieldValue.GetValue()), "Не заполнилось поле которое должно быть заполнено в классе операции, то есть не вызвался класс операций для документа");
grid.DeleteFirstRow();
docForm.Close();
}
Соответственно в тесте мы оперируем такими терминами как Сущности (BaseInDocumentImpl, BaseInDocument), Действиями (это то, что воплощается в кнопки, прикладной код — Operations, CreateDocument), и собственно указывать лямбда выражениями над чем мы хотим работать в сущности (ForMember(la => la.SomeNewField).GetField(), SomeNewField — это поле типа сущности).
Вот примерно так пишут тест. Выходит что предметная область теста совпадает с предметной областью прикладного разработчика и аналитика. Они оперируют одними и теми же понятиями, и в принципе понимают тест, но могут даже не видеть интерфейс, который они тестируют.
Основной смысл тестов — убедиться что на крайней линии сложная цепочка действий выполняется без каких-либо отклонений. Фактически что можно провести тот или иной бизнес-процесс. Например провести определенный документ и получить нужные данные.
Конечно такие тесты не способны детализировать интерфейс, если есть такая потребность, то можно делать вставки голым Selenium или JavaScript. Но как показала практика — стабильные тесты таким образом простые разработчики написать не могут. Нужно понимать работу сложного интерфейса, крайне динамичного. Это сложно.
В общем как-то так оно вышло.
А вы исключительно тестированием занимаетесь? Просто то, что вы описали — это работа одного-двух человек в течении месяца, полутора. Интересно как в вашей организации процесс тестирования поставлен.
У нас API разрабатывал я, при этом я же занимался частью View (серверная и клиентская). Ещё 2 человека занимались бэкендом. Это ядро. Один человек ведет TeamCity. Есть ещё 10 прикладных разработчиков, которые пишут бизнес-логику. На разработку первой очереди API для тестов ушел где-то месяц. С тех пор он регулярно дорабатывался, в последний раз была введена более жесткая типизация (на это потребовалось дня 3). Сам Selenium живет уже год, написано 70+ тестов, они проходят где-то час в 2 потока. Интересное наблюдение — на поддержку тестов уходит больше времени, чем на написание API, развертывание и написание самих тестов. С одной стороны это говорит о не слишком высоком качестве API, с другой стороны это можно объяснить высокой динамикой интерфейса (написанного на ExtJS). Но если подумать, то без API покрыть Selenium тесты такую систему вообще было бы нереально, если даже API тяжело стабилизировать.
В последнее время 1 из 3 падений теста говорили о реальной проблеме в системе, ещё 1 говорило о несоответствии логики теста логике (возможно изменившейся) системы, а последнее случалось из-за проблем с самим API теста. Как-то так.
Спасибо за статью и приведенный код! Кстати, похоже на мой здесь.… Но с той принципиальной разницей, что я использую DOM, а Вы, как я понял — объекты JavaScript, а Selenium для запуска браузера и каких-то не особо затратных операций. Что ж, это действительно интересно!
Да. Последнее время я занимаюсь именно автоматизацией тестирования, контролем регрессии и вещами вокруг этих областей. Я бы рассказал о нашем процессе тестирования, но не в комментариях))) Если Вам действительно это интересно, напишите мне в личку, я отвечу.
Да. Последнее время я занимаюсь именно автоматизацией тестирования, контролем регрессии и вещами вокруг этих областей. Я бы рассказал о нашем процессе тестирования, но не в комментариях))) Если Вам действительно это интересно, напишите мне в личку, я отвечу.
Да, все верно. Объекты JS, компоненты в JS и прочее. Парадигма такая — извлекать информацию с помощью JS команд через Selenium, делать действие с помощью IWebElement (клики, вводы и прочее). Получилось достаточно просто собрать модель тестируемой системы в тесте, и при этом имитировать пользовательские действия с помощью Selenium.
Меня правда огорчают проблемы при обновлении Web драйверов Selenium, но всегда можно найти костыли для решения.
Меня правда огорчают проблемы при обновлении Web драйверов Selenium, но всегда можно найти костыли для решения.
Для обхода StaleElementReferenceException вы настроили классных костылей, но на самом деле если бы разработчики селениума/вебдрайверов предусмотрели галочку «не кешировать ссылки» или «выполнить данный запрос с чистого листа» — все было бы гораздо проще!
Я точно так же обхожу StaleElementReferenceException, но это бред. Кто же сделает судьбоносный патч?
Я точно так же обхожу StaleElementReferenceException, но это бред. Кто же сделает судьбоносный патч?
Ну, в общем, Selenide как раз это и делает.
Любой вызов типа
Ну и соответственно умеет обрабатывать команды типа
Любой вызов типа
$("h2").shouldHave(text("Hello")) делает запрос с чистого листа. Причем не только если элемента нет, но и если элемент есть, но с неправильным текстом. Ну и соответственно умеет обрабатывать команды типа
$(".error-message").shouldNot(exist), что с обычным Selenium нетривиально.Не спорю, что это бред. Просто, как вариант, который не портит структуру предполагаемого проекта. Как костыль, вполне элегантный)))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Про Selenium и один «велосипед»