Наверняка многим из читающих эту статью есть чем поделиться в области автоматизации тестирования. Предлагаю делиться наработками в этой области в комментариях.
то я могу Вам предложить ознакомиться со своей наработкой. Я, кстати, о ней писал на хабре и скоро будет еще материал. Она базируется на Page Object'х, WebDriver API и задумывется как нечто кросс-платформенное и позволяющее работать как с браузерами, так и с мобильными приложениями:
— habrahabr.ru/post/242947/
— habrahabr.ru/post/244329/
Ссылка на github есть прямо в статьях.
После комментариев Dmitry_Zhariy и armid я подумал и решил добавить опрос.
Т.к. если это интересно, но сумбурно описано, то надо будет немного постараться. Но нужно, чтобы был в этом смысл.
Буду считать, что прошлогодняя статья была о набросоке, эта — я объявил о результате и она вводная перед циклом небольших тъюториалов.
Раньше я пытался привязать Page Object к окну. Теперь можно принять в учет ссылкам (не к одной ссылке как у thucydides, наприер), если страницу или какой-то виджет можно найти только по этим ссылкам. Их можно задавать рег. выражениями. Так же можно принять в учет индекса окна и заголовок для усиления.
Аналогично для мобильных приложений. Имя контекста, индекс (первый второй третий, т.к. может быть несколько WebView), активити для Android (можно и целый набор в виде регекспов).
Перечисленные выше моменты можно совместить и получить один универсальный page/screen object, если на данном конкретном приложении это реально.
Ок. Тогда. возможно что скоро я так и сделаю. Дело в том, что я хочу сделать публикации (заметьте, я уже принял ваше замечание) в каком-нибудь англоязычном комьюнити. А потом здесь будут теже статьи идти как перевод (если там хорошо примут) :)
Да, над стилем надо работать + найти больше времени. И вы правы, даже если это и хобби, объем радоты на одного человека немалый. Подсознательно пытаешься ничего не упустить
Вообще, задумывал рассказать о некоем решении, которое попробовал сделать в качестве эксперимента, который меня увлек. Это набор библиотек Java 8, которые должны упрощать работу с Selenium и Appium. Постольку поскольку я это задумал как сиквел — получилось так. Но не поздно — могу исправить :)
В первой статье (она во вступлении) — идеи (местами довольно сырые)
Здесь — результат
Побольше бы примеров, желательно из своей практики. Жду продолжения.
Мне тоже интересно, в чем принципиальное от Jenkins, Teamcity и т.п.
Допускаю, что процесс автотестирования может быть каким-то нетиповым и есть вероятность, что к готовой CI-системе нужно прикручивать какие-нибудь костыли. И правильно ли я понял, что можно просто настроить buildbot, а так же развернуть самописную CI систему с минимальными усилиями?
Спасибо за статью и приведенный код! Кстати, похоже на мой здесь.… Но с той принципиальной разницей, что я использую DOM, а Вы, как я понял — объекты JavaScript, а Selenium для запуска браузера и каких-то не особо затратных операций. Что ж, это действительно интересно!
Да. Последнее время я занимаюсь именно автоматизацией тестирования, контролем регрессии и вещами вокруг этих областей. Я бы рассказал о нашем процессе тестирования, но не в комментариях))) Если Вам действительно это интересно, напишите мне в личку, я отвечу.
По поводу первого пункта — наверное об этом я и говорил в своем комментарии выше.
Второй — никаких комментариев. Все уже сказано)
А вот третий пункт я не рассматривал. Нужно будет посмотреть, просто ради самообразования. Но, м.б. это действительно граница применения Page Object.
Да. Некоторые тестировщики сейчас могут подойти и пальцем показать, в какой строчке кода баг, и заставить фиксить))))
Что касается распараллеливания… Тут у меня есть некоторые пробелы. На моем текущем проекте используется TestComplete, который в принципе не поддерживает параллельный запуск — если только разбивать проект на части и запускать на разных машинах. Так что проблемы в теоретических и практических пробелах.
Пока я выполнял описанную в статье работу, то копнул и в эту сторону. Скажем — просто параллельные запуски тестов используя средства и настройки TestNG у меня получались без проблем, в том числе и на удаленных машинах. Но до использования каких-то build или continous integration серверов (надеюсь, я правильно понял вопрос) типа jenkins дело пока не дошло. А для экспериментальных целей мне пока хватило того, что получилось.
В своем заключении я как-то расплывчато описал предполагаемый конечный результат. Он бы наверное был таким…
Получился бы набор wrapper'ов для Webdriver'a. Каждый выполняет определенную функцию:
— управление браузерными окнами;
— выполнение действий над одним окном;
— обвертки, которые скрывают драйвер и сразу позволяют использовать интерфейсы HasInputDevises, Options, JavascriptExecutor и т. д. (очень полезные интерфейсы, кстати).
Все это бы являлось фундаментом для шаблонов, которые позволили бы строить модели сервисов или отдельных страниц. Причем, внутри этих моделей можно было бы использовать инструменты фрэймворков yandex qa tools (для Google Drive у меня это получилось), thucydides или Selenide (захотелось попробовать) + набор описанных выше инструментов.
Но, я думаю, такая модель избыточна для тестирования большинства вэб-приложений. Скорее она бы больше подошла для чего-то такого сложного, сравнимого с вэб-клиентом 1С или Google Drive.
Спасибо за оставленные комментарии. Получилось больше, чем я ожидал)
Сам бы я мог сказать вот что…
Понятно, что описанные наработки, впринципе, так и могут остаться наработками, так как все выше описанное делалось в свободное время. А какого-то серьезного проекта, на котором можно все это закрутить покрепче, пока к меня нет. Но, в любом случае, опыт оказался полезным.
Первое время я экспериментировал на вэб-клиенте 1С. А он нашпигован iframe'ами и при определенной настройке все открывает в новых окнах браузера. И работать с такими Page Object'ами было крайне неудобно из-за необходимости постоянно переключать драйвер. Решение созрело в тот момент, когда в голове выстроилась такая цепочка:
driver.switchTo.window(somehandle);
driver.switchTo.frame(someWebElement);
driver.switchTo.frame(anotherWebElement);
Получается что-то вроде пути, который нужно пройти перед выполнением метода. А дальше осталось только посмотреть в сторону АОП.
Раз уж пошла такая пьянка
то я могу Вам предложить ознакомиться со своей наработкой. Я, кстати, о ней писал на хабре и скоро будет еще материал. Она базируется на Page Object'х, WebDriver API и задумывется как нечто кросс-платформенное и позволяющее работать как с браузерами, так и с мобильными приложениями:
— habrahabr.ru/post/242947/
— habrahabr.ru/post/244329/
Ссылка на github есть прямо в статьях.
Если есть какие-то проблемы с видео, прошу рассказать о них :)
Т.к. если это интересно, но сумбурно описано, то надо будет немного постараться. Но нужно, чтобы был в этом смысл.
Буду считать, что прошлогодняя статья была о набросоке, эта — я объявил о результате и она вводная перед циклом небольших тъюториалов.
Эти правила будут использованы при автопереключении.
Раньше я пытался привязать Page Object к окну. Теперь можно принять в учет ссылкам (не к одной ссылке как у thucydides, наприер), если страницу или какой-то виджет можно найти только по этим ссылкам. Их можно задавать рег. выражениями. Так же можно принять в учет индекса окна и заголовок для усиления.
Аналогично для мобильных приложений. Имя контекста, индекс (первый второй третий, т.к. может быть несколько WebView), активити для Android (можно и целый набор в виде регекспов).
Перечисленные выше моменты можно совместить и получить один универсальный page/screen object, если на данном конкретном приложении это реально.
Ок. Тогда. возможно что скоро я так и сделаю. Дело в том, что я хочу сделать публикации (заметьте, я уже принял ваше замечание) в каком-нибудь англоязычном комьюнити. А потом здесь будут теже статьи идти как перевод (если там хорошо примут) :)
Да, над стилем надо работать + найти больше времени. И вы правы, даже если это и хобби, объем радоты на одного человека немалый. Подсознательно пытаешься ничего не упустить
В первой статье (она во вступлении) — идеи (местами довольно сырые)
Здесь — результат
Мне тоже интересно, в чем принципиальное от Jenkins, Teamcity и т.п.
Допускаю, что процесс автотестирования может быть каким-то нетиповым и есть вероятность, что к готовой CI-системе нужно прикручивать какие-нибудь костыли. И правильно ли я понял, что можно просто настроить buildbot, а так же развернуть самописную CI систему с минимальными усилиями?
Да. Последнее время я занимаюсь именно автоматизацией тестирования, контролем регрессии и вещами вокруг этих областей. Я бы рассказал о нашем процессе тестирования, но не в комментариях))) Если Вам действительно это интересно, напишите мне в личку, я отвечу.
Второй — никаких комментариев. Все уже сказано)
А вот третий пункт я не рассматривал. Нужно будет посмотреть, просто ради самообразования. Но, м.б. это действительно граница применения Page Object.
Да. Некоторые тестировщики сейчас могут подойти и пальцем показать, в какой строчке кода баг, и заставить фиксить))))
Что касается распараллеливания… Тут у меня есть некоторые пробелы. На моем текущем проекте используется TestComplete, который в принципе не поддерживает параллельный запуск — если только разбивать проект на части и запускать на разных машинах. Так что проблемы в теоретических и практических пробелах.
Пока я выполнял описанную в статье работу, то копнул и в эту сторону. Скажем — просто параллельные запуски тестов используя средства и настройки TestNG у меня получались без проблем, в том числе и на удаленных машинах. Но до использования каких-то build или continous integration серверов (надеюсь, я правильно понял вопрос) типа jenkins дело пока не дошло. А для экспериментальных целей мне пока хватило того, что получилось.
Но, эти пробелы, надеюсь, скоро закроются)
Получился бы набор wrapper'ов для Webdriver'a. Каждый выполняет определенную функцию:
— управление браузерными окнами;
— выполнение действий над одним окном;
— обвертки, которые скрывают драйвер и сразу позволяют использовать интерфейсы HasInputDevises, Options, JavascriptExecutor и т. д. (очень полезные интерфейсы, кстати).
Все это бы являлось фундаментом для шаблонов, которые позволили бы строить модели сервисов или отдельных страниц. Причем, внутри этих моделей можно было бы использовать инструменты фрэймворков yandex qa tools (для Google Drive у меня это получилось), thucydides или Selenide (захотелось попробовать) + набор описанных выше инструментов.
Но, я думаю, такая модель избыточна для тестирования большинства вэб-приложений. Скорее она бы больше подошла для чего-то такого сложного, сравнимого с вэб-клиентом 1С или Google Drive.
Сам бы я мог сказать вот что…
Понятно, что описанные наработки, впринципе, так и могут остаться наработками, так как все выше описанное делалось в свободное время. А какого-то серьезного проекта, на котором можно все это закрутить покрепче, пока к меня нет. Но, в любом случае, опыт оказался полезным.
Жду новых!
На самом деле я тоже до этого не сразу дошел.
Первое время я экспериментировал на вэб-клиенте 1С. А он нашпигован iframe'ами и при определенной настройке все открывает в новых окнах браузера. И работать с такими Page Object'ами было крайне неудобно из-за необходимости постоянно переключать драйвер. Решение созрело в тот момент, когда в голове выстроилась такая цепочка:
driver.switchTo.window(somehandle);
driver.switchTo.frame(someWebElement);
driver.switchTo.frame(anotherWebElement);
Получается что-то вроде пути, который нужно пройти перед выполнением метода. А дальше осталось только посмотреть в сторону АОП.