Released Selenide 7.0.0

Released Selenide 7.0.0

We turned 12, Java 17

Happy birthday!

Today is October 25. Today, 12 years ago the first commit in the Selenide project was created.

For the holiday, we released a major release Selenide 7.0.0 with the update immediately to Java 17.

Updated to Java 17

This day came!

To use Selenide 7.+, you will need to compile & run your tests with Java 17+.

How cool is that, right?

I know some of you don’t like this decision. You are still forced to run tests on Java 8.

But we are not guilty. As you know, Selenium 4.14+ upgraded from Java 8 to Java 11. So it was not possible to stay on Java 8 anyway. You have to update to Java 11 at least.

Now, there is a very simple reasoning. In any Java project, the most complex update is from Java 8 to Java 11. Compared to this, updating from Java 11 to Java 17 is much more simple. There is nothing to do there, really.

So just update your Java!

Life is too short to continue fiddling with Java 8

See PR 2522.

Updated dependencies

  • Updated Selenium from 4.13.0 to 4.14.1 (PR 2505) - requires Java 11+
  • Updated Appium from 8.6.0 to 9.0.0 (PR 2505) - requires Java 11+
  • Updated TestNG from 7.4.0 to 7.8.0 (PR 2505) - requires Java 11+

Fixed static initialization deadlock

This was an old potential problem in Selenide: class Condition and any of its subclasses depended on each other.
Therefore, under certain circumstances, a deadlock could occur when these classes were loaded simultaneously. Very unlikely, but theoretically possible.

More details about static initialization deadlock.

To fix the problem, we had to rename the base class Condition to WebElementCondition.

  1. Don’t worry, all your Condition.visible imports will remain unchanged.
  2. But if you have custom conditions, you will need to replace extends Condition by extends WebElementCondition.

See issue 2372 and PR 2453.

Actual value at the moment of check

Here we are talking not about web elements’ checks, but “new generation” checks: url, localStorage etc.

localStorage().shouldHave(item("mouse", "Jerry”));
sessionStorage().shouldHave(itemWithValue("mouse", "Jerry”));
clipboard().shouldHave(content("Remember me"));

Shortly, we made the error message in these checks more correct. Find details in issue 2500 and PR 2501.

Removed deprecated methods in Condition

Removed deprecated methods apply() and actualValue() in class Condition.

This will only affect you if you wrote your own custom checks. Now, instead of two methods apply() and actualValue(), you will need to implement only one method check.

See PR 2512.

Removed deprecated methods in CollectionCondition

Similarly to the previous change, it only affects you if you have custom checks for collections (extends CollectionCondition). Instead of two methods test and fail, you need to implement only one method check.

See PR 2520.

Removed deprecated methods in ElementsCollection

Be prepared for the shock.
Class ElementsCollection does not extend java.util.List anymore. From the very beginning, this inheritance occasionally added to ElementsCollection many unneeded methods (like remove(), removeRange, clear, subList and listIterator()) that we never intended to implement.
But users sometimes did use them. And even complained that these methods didn’t work.

Now we don’t have these methods and don’t have these problems.
Now $$ has only the methods we find useful. Amen.

P.S. If you have a loop over collection elements:

  for (SelenideElement el : $$("#selenide-users .user")) {

then it doesn’t compile anymore.

A fast solution is to add asFixedIterable() to $$:

  for (SelenideElement el : $$("#selenide-users .user").asFixedIterable()) {

But the right solution is to rewrite this code and avoid the loop. Most probably, you would better write your custom collection condition.

See PR 2513.

UPD From version 7.0.1, it compiles again.

Replaced deprecated class ElementsContainer by interface Container

If you extracted parts of your page objects to reusable containers (aka “widgets”), they usually inherited ElementsContainer:

class WeatherWidget extends ElementsContainer {
  @FindBy(id = "air")
  private SelenideElement airTemperature;

Now you will need to replace ElementsContainer by just Container:

class WeatherWidget implements Container {
  @FindBy(id = "air")
  private SelenideElement airTemperature;

Interface Container doesn’t have method getSelf() anymore. It had been @Deprecated for a long time. But if you still need it, we added a better alternative in Selenide 7.0.1: annotation @Self.

See PR 2523.

Replaced FileNotFoundException by FileNotDownloadedError

Before today, all methods like $.download() were declared as throws FileNotFoundException. And you had to suffer adding this pointless throws FileNotFoundException to your tests. Now you can clean up this trash and remove unnecessary catch (FileNotFoundException) if you had them.

Now methods like $.download() will throw FileNotDownloadedError which is inherited from AssertionError. You don’t need to declare nor catch it. If test could not download the file - test should fail.No additional processing is needed.

See PR 2526.

Renamed *Exception to *Error

Personally, I don’t think it matters at all.
But some users didn’t like that some of Selenide classes were named *Exception, but didn’t extend java.lang.Exception.

Well, we respect all opinions. Now Selenide classes inherited from java.lang.Error are named *Error.

See issue 2485 and PR 2530.

Removed support for deprecated WebDriverEventListener

We removed all methods like addListener() with a parameter of type

This class has been deprecated in Selenium for a long time.

You should use addListener() with parameter instead.

See PR 2516.

Removed deprecated Drag’n’drop methods

Yet another cleanup. Just replace




See PR 2519.

Removed deprecated methods $.getSelectedValue() and $.getSelectedText()

One more cleanup.

  1. Replace $.getSelectedValue() by $.getSelectedOptionValue()
  2. Replace $.getSelectedText() by $.getSelectedOptionText()

See PR 2521.

Removed deprecated TestNG annotations @Report and @GlobalTextReport

These annotations were not needed starting from Selenide 6.7.0. Just remove them. Yes, and delete TestNG, for that matter. ;)

See PR 2517.

Other cleanup

Few more cleanups:

  1. Replace
    new BearerTokenCredentials("pwd")


    new BearerTokenCredentials("domain", "pwd")
  2. Replace


    $.should(appear);  // or just $.shouldBe(visible)
  3. Replace, BASIC, "username", "password");

by, BASIC, new BasicAuthCredentials("username", "password"));

See PR 2518.

Towards progress!

Andrei Solntsev