2016-12-20 6 views
1

В моем наборе тестов appium/python есть тесты, для которых сначала требуется вход в систему. Примеры GitHub показывают только, как настроить веб-драйвер setUp/tearDown для каждого теста в пакете. В моем случае было бы здорово повторно использовать существующий сеанс webdriver для всех тестов.Как сеанс webdriver может быть повторно использован между тестами в классе в AWS Device Farm?

Однако методы setUpClass/tearDownClass выполняются для каждого метода тестирования в среде AWS Device Farm. Мои попытки создать webdriver как переменную класса не работали в AWS Device Farm (хотя и работали локально).

Каким будет оптимальный способ установки сеанса webdriver, войдите в приложение, затем запустите все тесты в наборе, повторно используя один и тот же сеанс веб-драйвера, а затем выйдите из приложения и выйдите из webdriver?

ответ

0

Я работаю в команде AWS Device Farm. Вы правильно изучили уроки по установке и разрыву из своих тестов, проведенных до и после каждого теста.

Каждый тест в ферме устройств работает против нового экземпляра appium server/session. Это помогает нам предоставлять пользователю более подробные отчеты и тестовые артефакты.

Мы также проводим линии, которые пользовательские тесты являются модульными, как определено большинством модулей тестирования. Это означает, что между испытаниями не существует зависимости.

Один из способов, а не лучший способ добиться того, что вы ищете, - это заставить все методы тестирования вызываться в последовательности, которая вам нравится, в центральном тестовом случае. Таким образом, вы можете войти и сделать другие вещи в этом случае. Недостатком, очевидно, является то, что если какой-либо из этих тестов завершится неудачей, он сообщит об отказе основного теста, и вам придется писать тесты, чтобы в журналах было очевидно, какая часть теста завершилась неудачей.

Второй способ заключается в том, чтобы пройти шаг входа в систему перед испытаниями, которые его требуют. Таким образом, ваши тесты также являются модульными и не зависят друг от друга.

Мы всегда открыты для обратной связи, и я отметил это как запрос функции. Надеюсь, это поможет.

+0

Спасибо, я отметил ваш ответ как решатель проблемы только потому, что он явно подтверждает проблему :) Вероятно, проблема не имеет немедленного решения в АПД. Оба предлагаемых подхода имеют значительные ограничения. Размещение всех моих тестов в одном огромном тесте ADF скроет множество тестовых характеристик, которые я бы хотел избежать. Размещение экземпляра/выхода webdriver и входа/выхода из системы в методах setUp/tearDown для каждого теста очевидно выполнимо, но, вероятно, значительно увеличит стоимость запуска этих тестов (надеюсь, это не основная причина этого подхода ADF к разделению тестов) – Ken

+0

Кен, Нет. Это было не где причина, даже отдаленно для ее настройки таким образом. Основная предпосылка, на которой мы основывали разделение, заключалась в том, что тесты пользователей будут модульными, так как не многие пользователи имеют модель зависимых тестов. Хотя я полностью понимаю, что это может быть полезно в некоторых случаях. Дайте мне знать, если я могу помочь с чем-либо еще. – NikofTime

 Смежные вопросы

  • Нет связанных вопросов^_^