Why is there no "ElementsLocatedBy" ExpectedConditions method that returns a Boolean?

[Jon Thor Austen]

Why is there no "ElementsLocatedBy" ExpectedConditions method that returns a Boolean?   Couldn't one be added?

Why?

I really think that using the language "visibilityOf" IMPLIES returning a Boolean value,
but as you can see here the method is defined to return a WebElement:

  static ExpectedCondition<WebElement> visibilityOfElementLocatedBy(By locator)

I think that SINCE this method returns a WebElement, a far better, less confusing name would have been:

  static ExpectedCondition<WebElement> returnVisibleElementLocatedBy(By locator)
 
And if that was the case, then visibilityOf could return a Boolean instead (and made safe from returning exceptions) :

  static ExpectedCondition<Boolean> visibilityOfElementLocatedBy(By locator)

[Andreas Tolfsen]

On 22 Jan 2015, at 15:54, Jon Thor Austen <aust...@gmail.com> wrote:
> Why is there no "ElementsLocatedBy" ExpectedConditions method that returns a Boolean? Couldn't one be added?

I’ll leave this for any of the Java binding developers to answer. My first thought is that I like that idea a lot (although shorter function names would be preferable).

Maybe this is worth discussing on selenium-developers@.

[Seva Lo]

It was named visibilityOfElementLocated because wait.until(visibilityOfElementLocated(By.id("button"))).click() reads well, arguably.

On Thursday, January 22, 2015 at 12:03:34 PM UTC-8, Jon Thor Austen wrote:

I tried to post on Selenium Developers google group but the permissions didn't allow me.

[David]

>> It was named visibilityOfElementLocated because wait.until(visibilityOfElementLocated(By.id("button"))).click() reads well, arguably.

Is that the primary use case for how that method is used? Naming based on how it's used would in ways make sense, assuming how it's used is intuitive to the user. If not, could document examples of how it's to be used on wiki or somewhere.

[Seva Lo]

Yes to your question.

If you are interested in contributing documentation, project can definitely use help there. Happy to help you get started.

Seva

[Jon Thor Austen]

I have to say that I don't agree that reads well.   If you read my original question, you would see that my suggested method names read much better :

    // click visible element on page

    WebElement we = wait.until(returnVisibleElementLocated(By.id("button")))

    we.click();

Do you see?  And then, with a properly named visibilityOfElementLocated method, you could do something like this:

    //  if error message is not visible on page for 5 seconds, then its ok to click button   

  Wait<WebDriver> wait = new FluentWait<>(driver).withTimeout(5, TimeUnit.SECONDS);
  Boolean cond =  wait.until(visibilityOfElementLocated(By.id("errorMessage")))
  softAssert.assertFalse(cond, "Button should not be clickable because error message is visible on page.");
  we.click();

-Jon

On Sunday, January 25, 2015 at 7:59:11 PM UTC-8, Seva Lo wrote:

[Andrew Muraco]

I think you are missing the subtlety of how Wait works.

I think you might want to explain your use-case on why you'd want to "wait" for a result like this (as in I want webdriver to wait until an element is visible or not)

How would webdriver know when it's done enough waiting? Would not have an element that matches be false or an error, or just more waiting?

Under the hood it would seriously complicate the way *Wait is implemented, consider this psuedo code for what wait.until basicly does with a boolean

Boolean result = null;

do {

  try { 

    result = expectation.apply(driver);

  } catch (SomeSpecifiedWebDriverExceptions exception) {

   result = null; (or false if you perfer)

  }

} while (result != true);

return result;

If you were trying to assert false with the result value, you would have to run the loop until the timeout which would make testing incredibly slow.

I think you are trying to over complicate what really is this:

wait.until(presenceOfElementLocatedBy(selector)).isDisplayed();

The problem with the above statement is that it would throw an error if the element is not even rendered, which depending on your use case would be the same as false or error.

From my own usage of webdriver, I usually look for something else that should be visible (ex like loaded data) before i check for things that shouldn't be on the page (ex no data message). If i check for the no data message too early, then I may endup checking for it while something unrelated is still going on (like a loading bar)

I hope this give you some food for thought about why the API was designed the way it is and why it's not likely that this specific thing is going to change, since it would make the API slow and or awkward to use.

[Jon Austen]

You may be misunderstanding my question:
1.  A wait.until for a visibility boolean that expires after, let's say, 5 seconds or less, would have a negligible effect on test speed.
2.  I suggested a change in the method name to improve readability but I am not necessarily suggesting you change how you currently code your solution.
3.  The boolean visibilityOfElementLocatedBy  is therefore a method "added" and is not a method changed (except by name).
4.  I think returning nulls from methods is not necessary and is weird from a test-driven perspective.  Just try unit testing it; it becomes a hack.
-Jon

--
You received this message because you are subscribed to a topic in the Google Groups "Selenium Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/selenium-users/X1GcQrZ53Bk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to selenium-user...@googlegroups.com.
To post to this group, send email to seleniu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-users/27c9582b-5c12-4774-acce-aec5444299f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jim Evans]

If I'm reading correctly, your question is "Why does the ExpectedCondition of visibilityOfElementLocatedBy return a WebElement instead of a boolean?" The answer is twofold, one of which, you've rejected, but is opinion-based, so it's not worth discussing. That first part really is, "It reads better." It would read as, "wait until [the] visibility of [the] element located by..." You reject that as that it doesn't read particularly well, but again, that's your opinion.

The second reason is that in the 80% case, if one is waiting for a condition based on an element, one wants subsequently to *use* that element, rather than have to reacquire it. Therefore, for that majority case, it's better to have the condition return the element so that one can immediately interact with it in the next statement. Yes, there are exceptions, and some coding styles (yours?) might make a boolean return more useful, but that's the reason for the reason it's named as it is.

[Andreas Tolfsen]

On 1 Feb 2015, at 17:23, Jon Austen <aust...@gmail.com> wrote:
> 4. I think returning nulls from methods is not necessary and is weird from a test-driven perspective.

Explicit waits looks for whether expected conditions
return a _falsy_ value. E.g. it doesn’t type check
and look for a binary value.

It loosely matches on the truthiness of the return
value. This is useful in many languages, because
structures such as empty sequences evaluate to false.

This allows conditions to return complex types, e.g.
web element references or objects. All of the explicit
wait implementations I’ve seen so far propagate this
return value to the callee.

That allows you to wait for an expected condition to
happen on e.g. a selector and use its return value,
a web element, to interact with it directly afterwards.

> Just try unit testing it; it becomes a hack.

Can you explain why this is weird and hacky?

[Jon Austen]

Thanks for the reply Andreas and Jim,

I have to say that I still don't have a complete answer to my question but that my perspective has changed a bit after your answers.   That being the case, I believe that it is possible that I might take your advice and find a way to check for "positive existence" of some other parent element that is "present element" on the DOM, and then, assuming the element was found, then use 'visibilityOf' to get the boolean visibility value of my "alert box" sub-element.   Not sure if this will really work for me but I am willing to give it a try.   This is an AJAX busy page and therefore I don't know how well it will work.

-Jon