Home

Автор: Энди Найт (Andy Knight)

Оригинал статьи: http://automationpanda.com/2017/12/03/the-airing-of-grievances-selenium-webdriver/

Перевод: Ольга Алифанова

Selenium WebDriver – это, фактически, стандарт для автоматизации Web UI. Отличный инструмент, но, как и все хорошее, зачастую используется неправильно. У меня много вопросов к использованию Selenium WebDriver, и сейчас вы узнаете об этом все!

WebDriver «Юнит-тесты»

«Юнит-тесты на WebDriver» напоминают квадратные круги – они по определению неверны логически. Если мне не изменяет память, юнит-тесты – это тесты белого ящика, что подразумевает прямой доступ к коду продукта. Тесты Web UI, использующие WebDriver – это тесты черного ящика, так как они взаимодействуют с активным, запущенным сайтом. Следовательно, они выше уровня юнит-тестов по определению. Не надо их так называть.

Когда все тесты – это Web-тесты

НЕТ! Тест-пирамида жизненно важна для здоровой стратегии тестирования. Web-тесты прекрасны тем, что тестируют сайт так, как бы с ним обращался пользователь, но они дорого стоят. По сравнению с тестами более низкого уровня они более хрупкие, требуют больших затрат на разработку, и занимают больше времени на прогон. К тому же на тестирование могут повлиять браузерные различия. Более того, проблемы на более низком уровне компонентов должны быть пойманы именно на этих уровнях! Безусловно, на уровне приложения вы увидите HTTP 400 и 500-ошибки, но их быстрее найти и исправить на сервисном уровне тестов. Разные уровни тестов снижают риск за счет оптимального соотношения полезности и затрат.

Когда WebDriver не убирает за собой

Каждый запуск WebDriver создает новый системный процесс, обслуживающий взаимодействие с браузером. Когда процесс автоматизации завершен, процесс WebDriver необязательно завершается вместе с ним. Очень важно, чтобы автотесты закрывали процесс WebDriver по завершении тестирования. Убедитесь, что очистка происходит даже в случае тупиковых исключений! В противном случае зомби-процессы продолжают жить на тест-машине, вызывая кучу проблем: закрытый доступ к файлам и директориям, высокий процент использования памяти, зря потраченные процессорные циклы, заблокированные сетевые порты. Эти проблемы калечат систему и могут даже сломать последующие тест-прогоны, особенно на распределенных тестовых машинах (вроде нодов Jenkins). Умоляю, остановите этот зомби-апокалипсис – всегда закрывайте процессы WebDriver!

Использование «Close» вместо «Quit»

Вне зависимости от языка программирования у WebDriver есть как close, так и quit-методы. Close закрывает текущую вкладку или окно браузера, а quit закрывает все окна и завершает процесс WebDriver. Убедитесь, что во время финальной чистки используется Quit. Если вы выполняете только Close – это приведет к зомби-процессам WebDriver. Это ошибка новичков.

Отсутствие оптимизации настройки/очистки посредством служебных вызовов

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

Веб-элементы без ID

Разработчики, нам нужно серьезно поговорить – дайте каждому важному элементу уникальный ID, ОЧЕНЬ ВАС ПРОШУ. WebDriver-вызовы куда проще писать, и они куда устойчивее при прогоне, если локаторы могут использовать ID вместо селекторов CSS или XPath. Давайте определимся с ID во время нашей трехсторонней встречи, и я смогу писать тесты, пока вы разрабатываете фичи. Определение, какие элементы импортируются, должно быть легким благодаря нашим макетам. Вы сбережете автоматизатором много времени и нервов, потому что нам не придется копаться в HTML в удивлении, что наши XPath не работают.

Изменение веб-элементов без предупреждения

Эй, разработчики, вот еще что – не меняйте структуру веб-страниц, не сообщив об этом нам! Локаторы WebDriver сломаются, если вы изменили веб-элементы. Даже, казалось бы, невинное изменение может стереть с лица земли сотни тестов. Автоматизация – задача нетривиальная. Изменения должны быть плановыми и вноситься с учетом автоматизации тестов.

Игнорирование модели Page Object

Модель Page Object – широко используемый шаблон дизайна для моделирования веб-страницы (или ее компонентов) как объекта в терминах ее элементов и пользовательского взаимодействия с ней. Она выносит взаимодействия с веб-интерфейсом на общий слой, который можно применять и применять в различных тестах. (Шаблон Screenplay тоже хорош – это более развитый вариант Page Object, руководство можно найти здесь). Игнорирование этой модели – это самоубийство для Selenium. В результате мы получим массовое дублирование кода.

Очернение XPath

XPath часто критикуют за то, что они медленнее, нежели CSS-селекторы. Это заявление – устаревшая чушь. Во многих случаях XPath опережает селекторы CSS – см. тут, тут и тут. Другая распространенная жалоба – на более сложный по сравнению с CSS синтаксис. Честно говоря, с моей точки зрения, они примерно равны в плане скорости изучения. XPath, к тому же, мощнее селекторов CSS, так как может уникально указать на любой элемент страницы.

Неэффективный доступ к веб-элементам

ID веб-элементов крайне упрощают доступ к ним. Однако в условиях отсутствия ID требуются другие локаторы. Старайтесь использовать локаторы, чтобы указывать на элементы, а не запрашивать список элементов (или родительскую/дочернюю цепочку), и затем пробегаться по коду. К примеру, я часто вижу код-ревью, где XPath возвращает список результатов с текстовыми маркерами, а затем программный код (C#, Java, что угодно) уходит в for-цикл, повторяющийся для каждого элемента в списке и завершающегося, когда найден элемент с нужным маркером. Просто добавьте [text()=’нужный текст’]” or “[contains(text(), ’нужный текст’)]” в XPath! Используйте локаторы на полную катушку!

Взаимодействие с веб-элементами, когда страница еще не готова

Автоматизация Web UI по определению полна гоночными состояниями. Убедитесь, что элементы готовы, прежде чем их вызывать – или готовьтесь увидеть кучу исключений вида «элемент не найден». Используйте ожидания WebDriver эффективно. Избегайте жестко закодированных ожиданий (вроде Thread.sleep в Java).

Ненастроенные таймауты

Запросам WebDriver нужны таймауты, изначально они повиснут навечно, если столкнутся с проблемой (см. онлайн-документацию по значениям таймаута по умолчанию). Значение таймаута должно быть настроено в соответствии с различными тест-окружениями и сайтами. Слишком короткие таймауты оборвут тест без необходимости, а слишком длинные – замедлят ценное время прогона.

Обсудить в форуме