Good night!

We have released Selenide 5.11.0.
This is the second quarantine release of Selenide in which we made a couple of breaking changes.

Changed the behaviour of shouldNot* methods for unexisting elements

Just look at the table below to understand what changed.
Assuming element h1 does not exist on a page:

Previous logic

A long time ago it was decided in Selenide: the check h1.shouldNotHave(text("foo")) should not fail. If the element <h1> does not exist, then it doesn’t have text “foo”. So, the condition “should not have text” is true.

Additionally, it seemed to be reasonable because the check h1.shouldNotHave(text("foo")) is the opposite to h1.shouldHave(text("foo")) which fails for an unexisting element.

New logic

But we realized that there was a problem with the previous approach: it allowed to make a mistake too easily. Namely, you could accidentally write a wrong locator, thus making a false-positive test. Test that was green, but didn’t check anything.

Now both h1.shouldHave(text("foo")) and h1.shouldNotHave(text("foo")) fail if <h1> is not found.

See issue 368 and PR 1116.

Now Selenide fails if SLF4J is not configured

If you get such an error:

java.lang.IllegalStateException: SLF4J is not configured. You will not see any Selenide logs. 
  Please add slf4j-simple.jar, slf4j-log4j12.jar or logback-classic.jar to your classpath. 
  See https://github.com/selenide/selenide/wiki/slf4j

don’t be afraid: just do what it says. It’s easy.

What problem we tried to solve?

The problem is: if you don’t have any SLF4J implementations in your project, you could miss some important Selenide logs, including “text report”. Now you are forced to include some of SLF4J implementations.

See issue 1114 and PR 1115.

Added method for partially checking the attribute value

Until now, Selenide had 2 methods for checking attributes:

1. presence of attribute, and
2. exact value of attribute:

  $("#domain-container").shouldHave(attribute("class"));
  $("#domain-container").shouldHave(attribute("class", "container"));

Now we added method attributeMatching for partially checking attribute value.
See examples in tests:

@Test
void canVerifyAttributeMatching() {
  $("#domain-container").shouldHave(attributeMatching("class", "contain.*"));  // class="container"
  $("#domain-container").shouldHave(attributeMatching("class", ".*tainer"));
  $("#domain-container").shouldHave(attributeMatching("class", ".+tain.+"));
}

See issue 996.
Thanks to Dmytro Stekanov for PR 1100.

Added method for getting the last screenshot

We added 2 new methods:

• Screenshots.getLastThreadScreenshot() - returns the last screenshot taken in current thread
• Screenshots.getThreadScreenshots() - returns all screenshots taken in current thread

Most of the users do not need those methods: Selenide adds screenshot details to error message anyway.
But those methods can be useful for those who write their own frameworks on top of Selenide or integrate Selenide with frameworks like Allure.

See issue 1029.
Thanks to Dmytro Stekanov for PR 1125.

Added annotation @CheckReturnValue to most of Selenide methods

It allows IDE (at least Intellij IDEA) to better analyze your tests and show warnings if you called some Selenide method, but forgot to check results:

Thanks to Yuriy Artamonov for PR 1106.

Added missing method Selectors.byTagName()

Just for consistency with By methods.

Thanks to Yuriy Artamonov for PR 1104.

Fixed screenshot URL

… in case when project is run in Jenkins, and the project path contains spaces.

See issue 1072.
Thanks to Dmytro Stekanov for PR 1098.

Disabled annoying warnings about Chrome extensions

Some folks saw those annoying warnings in Chrome:

Now we disabled them with this setting:

options.setExperimentalOption("excludeSwitches", new String[]{"enable-automation", "load-extension"});

Please let us know if it causes some problems in your projects.

See issue 1119 and PR 1120.

Now you can set selectorMode and assertionMode via system properties

… Just for consistency with other Selenide settings.

See commit 231597eb6229e.

Method $.getWrappedElement() doesn’t wait anymore

I guess most of you didn’t even know about this method.
A long time ago, it was added to give access to the original Selenium WebElement without any Selenide magic (just in case, if somebody should need it).
But Iakiv Kramarenko noticed that it still applies Selenide magic: method $.getWrappedElement() waited for presence of the WebElement.

Not it doesn’t wait anymore. If the element doesn’t exist - you will get org.openqa.selenium.NoSuchElementException.
And yes, you can also get the legendary StaleElementReferenceException.

See issue 1015 and PR 1124.

Statistics

And here is my favorite part: latest Selenide downloads statistics. We hit the line 130 thousands per months!

and 23 thousands of unique IPs:

Life is good!

Andrei Solntsev

selenide.org

19.04.20