Released Selenide 4.12.3

Released Selenide 4.12.3

JUnit 5 support and reloadable collections

Good day! The championship is finally finished, and we can get back to our favorite open-source projects.

Today we released Selenide 4.12.3

Let’s look what’s inside!

Added support for JUnit 5

As you know, Selenide has special support for the most popular testing frameworks: JUnit4 and TestNG. It means special “@Rules” or “Listeners”, which can periodically restart a browser, make screenshots etc.

Now we added similar support for JUnit 5 too:

  • BrowserStrategyExtension
  • ScreenShooterExtension
  • SoftAssertsExtension
  • TextReportExtension

Thanks to Aliaksandr Rasolka for PR 757

By the way, we have also rewritten Selenide own tests to JUnit5 and AssertJ. So you can look for JUnit5 examples there if you need.

Timeout for downloading files

As you know, Selenide has method $.download() for downloading files. It uses the standard setting Configuration.timeout to avoid too slow/hanging downloads.

But some files are expected to download slowly. For example, when generating some heavy reports. For such cases we added a download method with timeout parameter:

File hugeReport = $("#huge-report").download(100500);

See issue 758 - thanks to Yuri Ivanov for PR 761

Collection reloading on every method call

This changes caused hot discussions.

Collection is a list of matched elements returned by method$$. It returns ALL matched elements. Sometimes this list can be long. Sometimes it can make tests slower.


Before version 4.10.1, Selenide always loaded the whole collection on every method call. That’s why a trivial iterating over big collection (few hundreds of elements) could be slow:

$$("span").forEach(item ->;


From Selenide 4.10.1, we started caching collections. The iterating became faster, but we got new complains. Some people store collection to a variable and do expect that it will be reloaded all the time:

ElementsCollection movieTitles = $$(".film");
assertEquals("Black Panther", movieTitles.get(0).getText());
$("sort")).selectOption("Release Date");
assertEquals("The Irishman", movieTitles.get(0).getText());

In my opinion, this code is unnatural: if I expect the collection to be changed, it would be natural to call method $$ once again. That’s why I didn’t want to revert caching for some time.

But finally, “consistency” argument won. Method $ does reload element on every method call, so $$ should behave the same way.


So we chose a compromise: $$ reloads the collection on every method call except $$.iterator() and $$.listIterator(). So the iteration will be fast, and elements will be reloaded (almost) always. I don’t know if it was the right decision. The new behavior can also cause some unexpected effects and pains. We will see.


By the way, if you want to cache the collection explicitly, we added method $$.snapshot(). It returns a current state of the collection - “snapshot”. It will not reload collection elements anymore. Iterating and any checks will be faster. You can you use this method when you know that the elements will not be loaded dynamically.

See issue 696


Stay tuned!

Andrei Solntsev