Новый экземпляр WebDriver для каждого метода тестирования?

Question

Как лучше всего создавать экземпляры веб-драйверов в Selenium-webdriver? Один раз за тестовый метод, за тестовый класс или за тестовый прогон?

Кажется, что их (очень!) Довольно дорого раскрутить, но держать их открытыми между тестами может привести к утечке информации между методами испытаний.

Или есть альтернатива - один экземпляр веб-драйвера - это одно окно браузера (исключая всплывающие окна), или есть метод для запуска нового окна / сеанса с данного экземпляра драйвера?

Спасибо Matt

Answer 1

Я обнаружил, что повторное использование экземпляров браузера между методами тестирования значительно экономит время при использовании реальных браузеров, например Fire Fox. При запуске тестов с помощью HtmlUnitDriver выгоды очень мало.

Что касается опасности недетерминированных тестов, то это компромисс между полностью детерминированными тестами и вашим временем. Интеграционные тесты часто включают такие компромиссы. Если вам нужны полностью детерминированные интеграционные тесты, вам также следует беспокоиться об очистке состояния базы данных / сервера между тестовыми прогонами.

Одна вещь, которую вы обязательно должны сделать, если собираетесь использовать экземпляры браузера, - это очистить / сохранить куки между запусками.

driver.manage().deleteAllCookies();

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

Answer 2

Если ваша цель автоматизированного интеграционного тестирования - создать воспроизводимые тесты, то я бы порекомендовал новый экземпляр веб-драйвера для каждого выполнения теста.

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

Лично единственное, что мне кажется более неприятным, чем трудно воспроизводимая ошибка, - это недетерминированный тест, которому вы не доверяете.

(Это становится еще более важным для управления самими тестовыми данными, особенно когда вы смотрите на тесты, которые могут изменять постоянное состояние приложения, например операции CRUD.)

Да, дополнительное время выполнения теста стоит дорого, но лучше, чем тратить время на отладку ваших тестов.

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

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