Selenide: Лаконичные UI тесты на Java

Видимо не до конца понимаете. Упрощу пример:

Дано:

1. N тестовых машины

2. Набор из 50 тестов

Надо:

1. Запустить все тесты параллельно в IE

2. На каждой машине в один момент времени может быть запущено не более одного экземпляра браузера

 

Решение разбить 50 тестов на N блоков и параллельно их запустить не вариант:

1. Не будет цельного тест репорта.

2. Тесты могут быть зависимы друг от друга.

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

4. Падение тестовой машины (BSOD/LAN problem etc.) приведет к скипу всего блока

 

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

 

1. followLink: не разу не сталкивался с тем, что какой-либо драйвер не мог кликнуть по линку с href. Если вы столкнулись с проблемным линком, на котором клик не проходил - то уверяю вас, это было не правило, а исключение. Чем черевато тут open: во-первых - двойная загрузка страницы [click - waiting - open - waiting]; во-вторых - в href попросту может оказаться about:blank, а нужный код будет в onclick; в-третьих - функционал клика - что если клик по линку удаляет, например, документ - приложение после такого клика, за open по голове не погладит. 

2. fireEvent. Я вызываю у некого SelenideElement метод fireEvent, что я ожидаю? Что у этого элемента фаернится искомый эвент. А по факту эвент пройдет у неизвестно какого activeElement'а. А document.activeElement'ом может быть <img>,<div>,<span> и т.д.? Судя по описанию - врядли https://developer.mozilla.org/en-US/docs/Web/API/document.activeElement.

3. Идем в should, видим waitUntil. Идем в waitUntil, видим все тот же catch (WebDriverException ignore) {}. Зачем ждать: если локатор не валидный - он сам не поправится, если браузер упал - он сам не поднимется?

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

5. Плохие советы. http://jimevansmusic.blogspot.com/2012/08/youre-doing-it-wrong-protected-mode-and.html. Да и в javadoc написано

public static final java.lang.String INTRODUCE_FLAKINESS_BY_IGNORING_SECURITY_DOMAINS
Capability that defines to ignore ot not browser protected mode settings during starting by IEDriverServer. Setting this capability will make your tests unstable and hard to debug.

6. Работает до тех пор, пока не встретится элемент, типа <div>   <span></span> div_text </div>

Про Selenium Grid теперь многое стало понятно. Спасибо. 

Многие пункты спорные (например, с какой это стати на одной машине может быть не больше одного браузера одновременно? Конечно может быть и несколько!), но в целом идея понятна. 

1. С followLink ситуация простая: не нужно - не используй. Я даже, пожалуй, удалил бы этот метод, но теперь нельзя: вдруг кто использует.

Есть старый добрый click(), если он делает то, что надо - используй его. В чём проблема-то?

2. fireEvent: этот метод - ПРИВАТНЫЙ! Проблемы как таковой нет: вы не вызовете его на любом элементе. Говорю же, не надо лезь в дебри.

3. Тем не менее, если пропал браузер, или случилась ещё какая-то беда, в итоговом сообщении об ошибке это будет отражено.

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

5. Спасибо за наводку, уберу эту настройку в следующей версии.

6. А почему?

например, с какой это стати на одной машине может быть не больше одного браузера одновременно? Конечно может быть и несколько!

Может - но смотря каких, и смотря в какие количествах :)

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

А для IE это аксиома, даже дефолтовые настройки грида - это 5xFF, 5xChrome, 1xIE: http://code.google.com/p/selenium/wiki/InternetExplorerDriver 

Вот браузеров с синтетическими эвентами (Chrome, Opera) можно запускать сколько угодно, причем они не будут мешать нативным.. Но ресурсы же не резиновые, а тестовые машины, в большинстве своем, это VM, которые не вытянут и дефолтовый набор браузеров грида.
 

3. Будет. Но будет и "холостой" explicit wait.

6. По спецификации: http://www.w3.org/TR/xpath/#node-tests. text() - в действительности это не текст элемента, а функция, которая возвращает все текстовые ноды данного элемента. Т.е. в случае <div>  <span></span> div_text </div> имеется две текстовых ноды: //div/text()[1] == '   ',  //div/text()[2] == ' div_text '; а //div[contains(text(),'div_text')] ==//div[contains(text()[1],' div_text ')] == NoSuchElement

1 лайк

2 сообщения перенесены в новую тему: Можно ли изменить дефолтный браузер в самой конфигурации Selenide?

8 сообщений перенесены в новую тему: Selenide умеет перехватывать стандартные алерты авторизации?

5 сообщений перенесены в новую тему: Можно ли отменить ожидание загрузки страницы в selenide?

4 сообщения перенесены в новую тему: Где найти полную документацию по selenide?

5 сообщений перенесены в новую тему: Простой тест на Selenide не запускается, что я делаю не так?

9 сообщений перенесены в новую тему: Как добавить свои листенеры к Selenide коду?

Сообщение перенесено в новую тему: Почему я получаю NoSuchElementException в моем PageObject c selenide?

Сообщение перенесено в новую тему: А идентификация элементов в Selenide используется “на месте”?