How to use getArgs method of org.openqa.selenium.devtools.events.ConsoleEvent class

You can try this one too as CSS Selector

driver.findElement(By.cssSelector("input[type='button'][value='Open device access']")).click();

or

driver.findElement(By.cssSelector("input[type='button']")).click();

Java 8 streams are an example of a fluent interface, and are intended to allow writing in a functional programming style. There is a lot of disagreement over what breaks the LoD and whether it even matters, but all that aside, the example in the documentation for Stream shows that you are using it as intended by the Java language designers.

If that isn't enough for your reviewer, note that the purpose of the Law of Demeter (aka the principle of least knowledge) is to keep programs loosely-coupled by minimizing the number of classes that a class directly communicates with. When A has a B and B has a C, and you want A to make C do something, you should have it tell B to get it done and let B worry about the details of how and when C is used.

In this case, every intermediate method on Stream is returning another instance of Stream, so you are still only coupled to the Stream class. I would not consider this a Law of Demeter violation.

I would also say that any class in a language should be considered coupled to the language's standard library. Therefore, any standard library objects should be exempt from the Law of Demeter, since you can't uncouple from them anyway. Otherwise, you wouldn't even be able to call get on a List that was returned by an object, or deal with a Set of Map.Entry from Map.entrySet(). This would also cover Stream, of course.

I was suggested to break the code to first stream to collect to list and run another stream operation to do match( in short break it down into multiple streams as needed).

Storing intermediate objects in local variables does not fix a Law of Demeter violation, you would still be accessing objects returned by other objects. It sounds like your reviewer is just blindly dot-counting.

First of all lets be clear about what a WebElement is.

A WebElement is a reference to an element in the DOM.

A StaleElementException is thrown when the element you were interacting is destroyed and then recreated. Most complex web pages these days will move things about on the fly as the user interacts with it and this requires elements in the DOM to be destroyed and recreated.

When this happens the reference to the element in the DOM that you previously had becomes stale and you are no longer able to use this reference to interact with the element in the DOM. When this happens you will need to refresh your reference, or in real world terms find the element again.

My solution is to use xpath to find options that are children of the select. Any xpath method can be used to find the select; in this example I am finding the select by id.

List<WebElement> options = driver.findElements(By.xpath("//select[@id = 'selectId')]/option"));

for (WebElement option : options) {
    if (option.getText().contains("DOLLAR")) {
        option.click();
        break;
    }
}

After a little more thought I realize the option can be found entirely with xpath:

driver.findElements(By.xpath("//select[@id = 'selectId')]/option[contains(text(), 'DOLLAR')]")).click();

@Grasshopper 's answer points us to the exact modified constructor of FluentWait and your requirement of removing the deprecation warning from withTimeout and pollingEvery fields. Incase you are facing further difficulty you can use the line of code below :

import java.time.Duration;
//lines of code
Wait<WebDriver> gWait = new FluentWait<WebDriver>(pDriver).withTimeout(Duration.ofSeconds(100))
        .pollingEvery(Duration.ofMillis(600)).ignoring(NoSuchElementException.class);

You can find a detailed discussion in The type FluentWait is not generic; it cannot be parameterized with arguments error for FluentWait Class through Selenium and Java

Answering your first question:

Have a look at the Selenium API docs for ExpectedConditon.

I quote:

public interface ExpectedCondition<T>
extends com.google.common.base.Function<WebDriver,T>

You see, that ExpectedCondition inherited from google's Function interface, thus you can use it as an argument for the until() method.

As for your second question:

I don't think you can hand over a lambda just like that. Until method is waiting for a Predicate or Function (as you correctly mentioned).

Regarding the differences between Predicates and lambdas, have a look for example here

So you can try something like this instead, still using your lambda-expressions:

Predicate<WebDriver> myPredicate = x ->x.findElement(By.id("id")).isDisplayed();

WebDriverWait wait = (WebDriverWait)new WebDriverWait(driver, 10);
wait.until(myPredicate);

This class is part of the Guava library. It must be in your classpath. But libraries do not magically disappear from the classpath of a project when upgrading Java. Some one must have removed it.

Even though I'm somewhat late answering the question:

You can now use WebElement.isDisplayed() to check if an element is visible.

Note:

There are many reasons why an element could be invisible. Selenium tries cover most of them, but there are edge cases where it does not work as expected.

For example, isDisplayed() does return false if an element has display: none or opacity: 0, but at least in my test, it does not reliably detect if an element is covered by another due to CSS positioning.

Its not really possible to perform a 'mouse hover' action, instead you need to chain all of the actions that you want to achieve in one go. So move to the element that reveals the others, then during the same chain, move to the now revealed element and click on it.

When using Action Chains you have to remember to 'do it like a user would'.

Actions action = new Actions(webdriver);
WebElement we = webdriver.findElement(By.xpath("html/body/div[13]/ul/li[4]/a"));
action.moveToElement(we).moveToElement(webdriver.findElement(By.xpath("/expression-here"))).click().build().perform();