Кто-нибудь сталкивался, может видел какие-нибудь статьи выступления на тему построение общего фреймворка для UI тестирования и Web(пока больше Desktop интересует) и Mobile(iOS + Android)?
Что хотелось бы / как выглядит пока в теории:
Иметь какую-то общую кодовую базу для всех платформ и избежать дублирования
Вынести общую логику приёмочных тестов отдельно
Локаторы для разных платформ отдельно
Экшены по возможности переиспользовать (конечно не обойдётся без особенностей для каждой платформы)
Page Objects скорее Page Elements соответствуют React компонентам
Почему так:
React\React Native, в принципе всё строится на компонентах, работа которых будет не сильно отличаться от разных платформ (iOS, Android, Web-Desktop).
Бизнес сценарии везде одни, собственно их будет не так много, плотное покрытие будет уровнями ниже.
Думается, что на 3 платформы можно будет переиспользовать хотя бы 50-60% кода, что уже будет проще поддерживать, меньше писать.
Гуглил, пока ничего не нашёл, но у меня было ощущение, что когда-то видел про подобные решения.
Что интересует:
Какие были проблемы, как решали
Какие инструменты использовали
Что получилось, как оценили
Может кто видел что-то на эту тему или даже опытом поделится?
P.S. Текущий стек на Python, но это не принципиально, интересуют общие решения и какие грабли встретились. А вообще копаю в сторону Selenium + Appium + Py.test + что-то из (Selene/Webium/PyPom), можно конечно и свой велосипед писать, но не хочется, пока вроде на Selene выглядит всё хорошо.
Привет. Мы работаем с Protractor + Appium, но у нас Mobile Web, В принципе точно так же можно сделать и для Native/Hybrid но наверное немного больше будет заморочек с PO и локаторами.
Какие были проблемы, как решали
настройка аппиума на сервере
Protractor асинхронный и надо делать много приседаний чтоб тесты были стабильными
Какие инструменты использовали
Protractor + Appium
Что получилось, как оценили
У нас были тести на Web, Но Chrome emulator не отображает действительность для IOS и Самсунг Браузеров, по этому решили запускать тесты на реальных девайсах. Просто прикрутили конфигурирования Аппиума и все взлетело из коробки.
Спасибо за ответ, а получилось тестовые сценарии вынести в отдельный уровень?
Как решали проблемы с тем, что на разных платформах разный UX(разные гайдлайны)?
Как оценили поддержку такого решения?
Так как у нас mobile web, то приложения очень похожу, конечно сами элементы отличаются, но место нахождения и функционал одинаковый, так что у нас одни сценарии под все платформы.
Для всех платформ мы добавляли test-id - локаторы на каждый необходимый элемент.
-Как оценили поддержку такого решения?
Очень сильно зависит от размеров проекта.
На сколько у вас функционал отличается для IOS/ Android/ Web?
Спасибо, за подсказку, да я смотрел на него и он меня пока отпугнул - уж больно монструозный, страшно, если на долгом пути что-то сломается - можно долго разбираться.
Идея типизированных элементов (отличие от селена) мне не актуальна и вообще такой подход не особо целесообразен из моего опыта.
Там больше готовых методов, по работе с элементами(например hover_and_click, наводимся по тексту на один элемент, ждём что появится другой и нажимаем на него, например), но это не такой большой плюс учитывая сколько надо времени погружаться в него.
Пока селен привлекает именно более легковесным подходом, за день всё прикрутил, пока устраивает.
// тест
I.click('~startUserRegistrationCD');
I.fillField('~email of the customer', 'Nothing special'));
I.see('davert@codecept.io', '~email of the customer'));
// использование разных локаторов на разных системах
I.click({
android: '//android.widget.Button',
ios: '//UIAApplication[1]/UIAWindow[1]/UIAButton[1]',
web: '#clickMe'
});
// использование разного кода в зависимости от платформы
I.runOnAndroid(() => );
I.runOnIOS(() => );
I.runInWeb(() => );
Сама структура теста не будет зависеть от платформы.
Ну а также сам синтаксис команд больше приближен к бизнес-логике чем к технической реализации, что делает тесты более понятными и выразительными.
Можно еще на Serenity посмотреть.
Для различных платформ указываются локаторы для элемента, а при выполнении выбирается нужный в зависимости от запущенной платформы:
Я такую возможность закладывал на уровне пейж объектов.
Связка - appium + selenide
Грубо говоря, при запуске сьюта передается параметр - иос, андроид или веб…
В зависимости от параметра происходит инициализация полей в конструкторе пейдж объекта:
public Login() {
switch (ENVIRONMENT) {
case WEB:
break;
case ANDROID:
registerButton = By.id(APP_ID + "register_btn");
loginButton = By.id(APP_ID + "login_btn");
facebookButton = By.id(APP_ID + "login_btn_facebook");
googleButton = By.id(APP_ID + "login_btn_google");
break;
case IOS:
break;
}
}
Соответственно, если бизнес логика одна и та же - тесты в основной массе должны работать одинаково.
Вариант с аннотациями мне не нравится от слова совсем - если на страница несколько десятков элементов - слишком много лишнего текста выходит.
Да, примерно всё так и сделал, только на пайтоне это получше смотрится
Собственно вопрос больше про опыт поддержки и использования такого решения, например, когда кейсов много становится, ну и 3 платформы могут с разной скоростью развиваться…
Я не очень верю, что в реальной жизни геркин-спецификации нужны, чаще всего это просто лишний слой (при этом есть опыт написания и поддержки 1000+ UI тестов c API прекондишинами), редко кто-то эти спецификации кроме автоматизаторов читает\пишет, зелёные тесты никто не смотрит, а красные: либо хватает сообщения об ошибке\скриншота из тестового фреймворка либо автоматизаторы идут уровнем ниже…
Сложности почти не добавляешь - получение нужного драйвера (аппиум\селениум) и словарь локаторов + как-то разрешать разный UX\функционал платформ, но взамен -
меньше кода(если появился\поменялся функционал на одной платформе, потом добавить\обновить этот кейс на другую платформу почти ничего не стоит)
Это то как выглядит сейчас - и хочется услышать про подводные камни от тех, кто с этим работал.
Тесты в несколько потоков можно вот так запускать: Advanced Usage | CodeceptJS
Пока ещё для мобильных платформ увы не тестировали, но по идее должно и там заработать
Из примера вижу, что codecept предлагает запустить несколько одинаковы потоков тестов с разными конфигурациями, но это не так важно (можно через CI запустить несколько job с разными параметрами), хоть и неплохо.
Даже при одной кодовой базе на все платформы что-то, надо под каждую тюнить и собирать приложения отдельно…
Важнее, чтобы была быстрая обратная связь и не писать самому распараллеливание потоков\процессов, т.е. параллелить сами тесты.
testomat.io управление авто тестами
