Как красиво установить Capabilities для Appium?

мобильные appium
, ,
#1

На данный момент я пишу скелет для второй версии моих тестов. В первой версии были задействованы только андроиды, несколько устройств параллельно, в этой будет Android+iOS в параллельном испольнении. Сейчас капабилитиес устанавливаются таким образом:
@Parameters({“folderAppName”, “fileAppName”, “udid1”, “noReset”, “deviceName1”, “platformVersion1”, “appPackage”, “language1”, “port”, “phoneNum1”, “name1”, “wifi1”, “mobileData1”, “wifiOff1”, “mobileDataOff1”, “wifiUpper1”, “deleteNotifications1”})

@BeforeClass
public void setDevice (String _folderAppName, String _fileAppName, String _udid,
                String _noReset, String _deviceName, String _platformVersion,
                String _appPackage, String _language,  String _port,
                String _phoneNum, String _name, String _wifi, String _mobileData,
                String _wifiOff, String _mobileDataOff,
                @Optional("false") Boolean _wifiUpper, String _deleteNotifications){

    Capabilities capabilties = SetterCapabilities.setCapabilities( _folderAppName,  _fileAppName, _udid,_noReset,  _deviceName,  _platformVersion,                                                                  _appPackage, _language);
    device = new Device(capabilties, _port, _phoneNum, _name, _wifi, _mobileData, _wifiOff, _mobileDataOff, _wifiUpper, _deleteNotifications);
}

где все параметры берутся из xml файла.
По моему выглядит слишком громоздко. И xml файл становится очень большим, когда в тестах участвуют несколько устройств.
Как можно более изящным способом установить Capabilities?

#2

Json или Yaml форматы в помощь.

2 лайка
#3

Параллелизация такого типа делается на уровне CI, но никак не на уровне тестов/сьютов.

#4

Почему? Через селениум грид разве не получится?

#5

А причем тут грид? Грид к вашей параметризации отношения не имеет.
Я про то, что хардкодить окружение/конфигурацию_стенда в сьют слегка не верный подход.

#6 
в этой будет Android+iOS в параллельном испольнении.

Параллелизация такого типа делается на уровне CI, но никак не на уровне тестов/сьютов.

У меня параллелизация в андроидах реализована с помощью грида, и сейчас собираюсь таким же образом делать. И я ищу более изящные способы взять настройки для капабилитес, чем сейчас из xml. При чем тут CI?

#7

При том, что это и есть самый изящный способ “взять настройки для капабилитес” в вашем случае. Сегодня вам надо ios9,3+ios10.0+android5,0+android6.0+en+fr+dev.app+release.app, а завтра только ios10.0+en+release.app - все это должно конфигурироваться непринужденно и “из-вне”.

ps: годная библиотека для properties

1 лайк
#8

То есть я беру какой нибудь парсер json, кормлю ему путь до файла, он считывает, так? А путь до файла прописываем в xml? Или нет?

#9

Путь к файлу можно делать относительный т.е. от корня проекта, вот интересно а как вы XML файл свой считываете, также и JSon…
PS: предпочтительней Yaml меньше мусора, единственно внимательно следить за пробелами. А так юзайте что посчитаете удобнее…

#10

Сейчас настройки указаны как parametr в testng.xml, и считываются в @Parameters. Но это как то криво выглядит, поэтому я сейчас и спрашиваю, как лучше. Еще у меня есть json файлики для грида.

#11

Зависит от того, как планируется использовать и подкладывать конфигурации.

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

Если надо хранить несколько конфигураций, создаем опять же в одном файле именованные конфигурации. А нужное имя передаем хоть в xml параметром, хоть как системное свойство при запуске - смотря по тому, откуда тесты будут запускаться.

1 лайк
#12

Selenium Grid поддерживает json конфигурацию в Capabilities по дефолту

#13

Товарищи - в-тему-отвечатели. Может хватит думать “как”, а начать думать “зачем”?
У топик-стартера 17 параметров… 17… Если минимально предположить, что они бинарны - то полное покрытие это 131072 вариантов.
А если вдуматься зачем они вообще - можно легко нарисовать себе в воображении, какое мессиво у ТС сейчас в сьюте, и насколько оно станет более мясистым некоторое время спустя. И выносить это “мясо” в другое место не вариант - его вес не изменится.

#14

Я в курсе. И?

#15

При чем тут покрытие? Это параметры для конкретного девайса, и большинство из них не бинарны.

#16

Повторюсь в последний раз - тест/сьют не должны знать ничего о тестовом стенде.
Можете прикинуть, как будет выглядеть ваш сьют для 10 android devices + 10 ios devices?

#17

У топик-стартера 17 параметров… 17… Если минимально предположить, что они бинарны - то полное покрытие это 131072 вариантов.

А вы где то встречали,что бы необходимо было перебрать в тестах параметры для мобильных устройств и их вариаций? И все они были бы бинарны? И прогнать еще по ним по всем тесты? Я - нет.

#18

В моих тестах затрагиваются некоторые нативные вещи, такие как настройки вай-фай, тип скроллинга при расшаривании (для андроида), камера и т.д. . И поэтому приходится все это учитывать.

#19

ну так сделайте json конфигурации себе и храните капабилити там, можно проперти файли сделать и читать их в коде … чет не вижу тут ботлнека никакого,… в одном фреймворке ми вообще все параметри драйвера через -D передавали

#20

Посмотрите, как здесь реализовано, например:

Может, какие идеи пригодятся. Думаю, CapabilitiesManager и работа с портами вполне могут пригодиться.

Я вообще сам сделал чуть иначе - у меня все общие настройки убраны в параметры сьюта, device specific - типа версии андроида, сдк, удид и тп при запуске собираются со всех подключенных девайсов…

Если так подумать:
(String _folderAppName, - очевидно, для всех девайсов один параметр? можно вынести в отдельный конфиг с параметрами сьюта
String _fileAppName, - аналогично
String _udid, - можно собирать с девайсов в рантайме

String _noReset, - можно вынести в параметры сьюта
String _deviceName, - опять таки, я в рантайме собираю (Manufacturer + Model)
String _platformVersion, - можно собирать с девайсов в рантайме
String _appPackage, - опять же, можно выкинуть в общие параметры?
String _language, - я в параметры сьюта убрал… при необходимости указываю нужную локаль в параметрах, девайсы и тесты переключаются на соответствующий язык…
String _port, - в ссылке выше неплохая реализация…

Вот то, что дальше, не комментирую, это уже ваша специфика :slight_smile:
Если я правильно понимаю, они для всех девайсов разные?
Вот их бы и вынесли в json, например (с привязкой к udid девайса)
String _phoneNum,
String _name,
String _wifi,
String _mobileData,
String _wifiOff,
String _mobileDataOff,
@Optional(“false”)
Boolean _wifiUpper,
String _deleteNotifications)

В общем, не знаю - красиво это или нет, чисто мои пять копеек:)

2 лайка