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:
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
File hugeReport = $("#huge-report").download(100500);
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 -> item.is(visible));
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()); $(By.name("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
$$ 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
$$.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
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
- We found a presentation about Selenide by Alexander Bondarev from Determine from some Nerd’s Day at Provectus. There is also a video.
- It finally happened! Selenide got to some Technology Radar with a title “Selenide as new standard”. See source
- Welcome to Agile Automation Days October 15-16 to see Workshop: Jump into the KISS UI-Test automation with Selenide