Today is January, 23.
Let’s meet the new update: Selenide 5.18.0.
Let me invite you to take a small virtual tour of the changes in 5.18.0.
Make yourself comfortable.
We disabled webdriver logs by default
Starting from version 5.13.0, Selenide wrote webdriver logs to files
It seemed to be useful at that moment. But later we realized that these logs take quite a lot of disk space, and nobody really needs to read them in most cases. That’s why we decided to disable them by default.
If you need those webdriver logs, you can still enable them with setting
Configuration.webdriverLogsEnabled = true.
See issue 1365 and PR 1379.
Changed “timeout” parameter type from Long to Duration
… in collection methods. Now instead of
it is fashionable to write
See issue 1377.
Thanks to Ostap Oleksyn for PR 1377.
Speed up search of inner shadow dom elements
One of features that do exist in Selenide, but not in Selenium webdriver is shadow dom:
$(shadowCss("p", "#shadow-host", "#inner-shadow-host")) .shouldHave(text("The Shadow-DOM inside another shadow tree"));
There might be multiple shadow roots inside of other shadow roots.
To find all elements inside inner shadow roots, method
every shadow root separately. It might be slow because every call to webdriver takes time.
which finds all elements in all inner shadow roots with one call.
See PR 1373.
A separate “thank you” goes to sakamoto66 for issue 1246 and PR 1233 which unfortunately was not merged, but inspired us for this optimization.
Selenide user pavelpp detected a bug in Selenide when used
not in combination with
$(".lolkek").shouldNotBe(visible, ofSeconds(5)); // works $(".lolkek").shouldNotBe(and("foo", visible)); // fails $(".lolkek").shouldNotBe(or("foo", visible)); // fails
Now we fixed it. All three lines don’t throw errors anymore.
See issue 1369 and PR 1370.
By the way, we now forbid using
or with only one condition.
In other words, line
or("foo", visible) doesn’t compile anymore.
You have to use at least two condition, like
or("foo", visible, enabled).
Agree, this is logical.
We detect conflict in “browserName” capability
We recently realized that there are two settings for specifying browser:
- The primary -
- Another -
Configuration.browserCapabilities["browserName"](I don’t really know why it’s needed)
And you might get an unexpected browser opened if you haven’t set the first one, but set the second one. Now Selenide detects such a conflict and throws an exception:
IllegalArgumentException: Conflicting browser name: 'chrome' vs. 'firefox'
Let me repeat: setting
Configuration.browser is enough in all cases. As far as I know, the second setting is never needed.
See issue 1366 and PR 1374.
Fixed displaying timeout parameter in reports
Recently we added to
$.should* methods parameter
timeout of type
Then we realized it was displayed quite unclearly in Selenide/Allure reports.
For example, line
$("h1").shouldBe(visible, Duration.ofSeconds(1)) looked like this in a report:
$("h1") should be([visible, PT1M])
Though this “PT1M” is an ISO-compatible representation and means “time period 1 minute”, we decided to replace it by more familiar “300 ms”, “1s”, “1.500 s.” etc.
See issue 1376 and PR 1378.
Upgraded to WebDriverManager 4.3.1
As usually, see their changelog here.
It’s the end of our excursion. Feel free to update and share your feedback.
Create issues in github, complain in chats, swear in twitter.
Here is an final downloads statistics of Selenide for year 2020. Not bad!
Happy current year!