Після поновлення Java-бібліотеки Selenium до версії 3.3.1 користувачі, у яких були створені свої власні умови для явних очікувань, помітили, що вони перестали працювати.

Що сталося? І, головне, що робити?

Оновлення в своєму проекті залежність від Guava до версії 21 і проблема повинна зникнути.

TL; DR

Read more: Чому в 3.3.1 перестали працювати предикати в явних очікуваннях?

Офіційні зовнішні інтерфейси для інтеграції додатків з браузерами не дуже добре пристосовані для "тонкого" управління браузерами. Вони головним чином розраховані на те, що движок браузера буде вбудований в додаток і в ньому будуть просто відкриватися сторінки. Однак Selenium вимагає більш тісної інтеграції. І хто може реалізувати це краще, ніж сам виробник браузера?

Всі, хто використовує Selenium, вже звикли до того, що браузер Internet Explorer самий повільний з усіх. Але чи поширюється це правило на браузер Edge, драйвер для якого робить безпосередньо компанія Microsoft?

Подивіться, наприклад, на ці результати порівняння швидкості роботи різних локаторів в Edge, Chrome і Firefox .

Ось підсумкова таблиця з результатами (вказано час виконання 100 запитів різного типу до однієї і тієї ж сторінці):

Locator Firefox Chrome Edge name 1377 ms 929 ms 204 ms className +1795 ms 902 ms 199 ms id 1600 ms 851 ms 262 ms linkText 9056 ms 1522 ms 238 ms xpath 2229 ms 919 ms 247 ms cssSelector 1280 ms 809 ms 219 ms

Edge обганяє конкурентів мінімум в 3 рази за всіма типами локаторів!

Ну а якщо він і на інших типах операцій виявиться швидше за інших браузерів ... Вам не здається, що починається новий виток війни браузерів, сформовану рівновагу порушено?

Не всі знають, що всередині Java 8 захований браузер. Ну, не повноцінний браузер, звичайно, а движок. Він є частиною бібліотеки JavaFX, призначеної для створення користувацьких інтерфейсів, і дозволяє реалізувати WebView , Тобто вбудовані вікна, в яких промальовується веб-сторінки.

І це не якийсь саморобний движок з обмеженими можливостями, а справжнісінький WebKit!

Залишилося тільки реалізувати для нього драйвер, і можна запускати тести в headless-режимі, не встановлюючи взагалі нічого додатково - тільки Java 8, Selenium і ваші тести.

Поспішаю вас порадувати, такий драйвер вже існує: jBrowserDriver

Правда йому поки всього три місяці від народження і в ньому ще напевно чимало багів, але я б все одно запропонував спробувати його як альтернативу драйверу для PhantomJS.

Письменники тестів на C # регулярно запитують - ось для Java є чудовий інструмент BrowserMob, який дозволяє перехоплювати запити і робити всякі інші цікаві штуки - а нам, письменникам тестів на C #, нам що використовувати?

Раніше я зазвичай рекомендував Fiddler Core . Це чудовий інструмент, але у нього є один великий недолік - безкоштовна ліцензія тільки для персонального використання, будь-яке комерційне використання вимагає придбання іншої ліцензії. І проблема навіть не в ціні, а в необхідності все це оформляти, проводити через бухгалтерію ... Відразу якось пропадає бажання користуватися інструментом.

Але під час чергового тренінгу, коли мені знову поставили це питання, я раптово погуглити - і виявив новий інструмент!

Зустрічайте героя: Titanium Web Proxy , Встановлюється в пару кліків з NuGet і розповсюджується під ліцензією Apache 2.0.

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

Зазвичай на конференціях трапляються всілякі приємні анонси - нові продукти, нові технології - швидше, вище, сильніше.

На жаль, іноді буває і навпаки.

SeleniumConf 2015 приніс сумну звістку: Ivan De Marino, автор інструменту Ghostdriver, драйвера для PhantomJS , Оголосив про те, що він більше не має можливості продовжувати роботу над цим драйвером.

У зв'язку з цим проект шукає нового господаря, який зможе розвивати інструмент далі. Зокрема, необхідно привести його до згоди з новою недавно випущеної версією PhantomJS 2.x з одного боку, і з поточною версією стандарту W3C WebDriver з іншого боку.

Кому не байдужа доля Ghostdriver - записуватися в добровольці можна тут .

Примітка: описане нижче поведінку було покращено у версії 2.52, почитати про це можна тут .

Я передбачаю, що це питання може виникнути у деяких користувачів після виходу версії Selenium 2.48.

Тому що операція click з використанням синтезованих подій буде працювати не так, як раніше. Краще, звичайно :) Але - не так, як раніше. Вона буде кликати по самому верхньому елементу.

Говорячи технічно більш точно, коли у якогось елементу викликається метод click, драйвер спочатку намагається проскролліровать сторінку так, щоб елемент виявився в області видимості, після цього він визначає положення і розмір елемента, потім обчислює координати центру і клацає в цю точку. Але в браузері елементи розташовуються "в кілька шарів", це можна наочно побачити в браузері Firefox, використовуючи режим 3D View. Тому в точці, куди виконується click, цілком може перебувати якийсь інший елемент. І тоді драйвер клацне по цьому вищерозміщений елементу, а не по тому, в якому викликався метод click.

Раніше такого ефекту можна було досягти тільки з використанням нативних подій. Їх більше немає. Але зате синтезовані стають "більш нативними".