How to use startSession method of org.openqa.selenium.remote.RemoteWebDriver class

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.

In my case I had something similar, but the error was in the folder name I used. I describe the path as C:/myFolder instead of C:\myFolder.

In previous version of ChromeDriver the first approach was still valid. Now it looks like this is not working anymore giving some Download error.

You should read up on what implicit wait actually does and how it works.

http://www.seleniumhq.org/docs/04_webdriver_advanced.jsp#implicit-waits

It's not something that you call to wait for 10 seconds, it only comes into play when an element that is being searched for is not available... then the implicit wait is triggered and that element is polled up to the 10s. If the element is already there, then there is no wait time. Thread.sleep() pauses execution no matter what but is not a good practice.

You need to call ignoring with an exception to ignore while the WebDriver will wait.

FluentWait<WebDriver> fluentWait = new FluentWait<>(driver)
        .withTimeout(30, TimeUnit.SECONDS)
        .pollingEvery(200, TimeUnit.MILLISECONDS)
        .ignoring(NoSuchElementException.class);

See the documentation of FluentWait for more information. But beware that this condition is already implemented in ExpectedConditions, so you should use:

WebElement element = (new WebDriverWait(driver, 10))
   .until(ExpectedConditions.elementToBeClickable(By.id("someid")));

*Fewer versions of Selenium:

withTimeout(long, TimeUnit) has become withTimeout(Duration)
pollingEvery(long, TimeUnit) has become pollingEvery(Duration)

So the code will look as such:

FluentWait<WebDriver> fluentWait = new FluentWait<>(driver)
        .withTimeout(Duration.ofSeconds(30)
        .pollingEvery(Duration.ofMillis(200)
        .ignoring(NoSuchElementException.class);

A basic tutorial for waiting can be found here.

You should use file address like this:

driver.get("C:\\Users\\sharmayo\\Desktop\\testlogin.html");

instead of:

driver.get("C://Users//sharmayo//Desktop//testlogin.html");

 if (attribute.equals(null)) {
    return true;
  }`

If attribute is null then .equals call will lead to NPE. Try with attribute == null.

this below code works for me in Selenium 3 and chrome version 58.

    WebDriver driver = new ChromeDriver();
    driver.get("http://yahoo.com");  
    ((JavascriptExecutor)driver).executeScript("window.open()");
    ArrayList<String> tabs = new ArrayList<String>(driver.getWindowHandles());
    driver.switchTo().window(tabs.get(1));
    driver.get("http://google.com");

There are a couple of ways you can accomplish this. If you insist on using XPath to do it, you need to add the context node to the locator, like this:

WebElement parentElement = childElement.findElement(By.xpath("./.."));

Alternatively, you can use the JavascriptExecutor interface, which might be slightly more performant. That would look like this:

// NOTE: broken into separate statements for clarity. Could be done as one statement.
JavascriptExecutor executor = (JavascriptExecutor)driver;
WebElement parentElement = (WebElement)executor.executeScript("return arguments[0].parentNode;", childElement);

If anyone actually knew a general and always-applicable answer, it would have been implemented everywhere ages ago and would make our lives SO much easier.

There are many things you can do, but every single one of them has a problem:

1. As Ashwin Prabhu said, if you know the script well, you can observe its behaviour and track some of its variables on window or document etc. This solution, however, is not for everyone and can be used only by you and only on a limited set of pages.

2. Your solution by observing the HTML code and whether it has or hasn't been changed for some time is not bad (also, there is a method to get the original and not-edited HTML directly by WebDriver), but:

   • It takes a long time to actually assert a page and could prolong the test significantly.
   • You never know what the right interval is. The script might be downloading something big that takes more than 500 ms. There are several scripts on our company's internal page that take several seconds in IE. Your computer may be temporarily short on resources - say that an antivirus will make your CPU work fully, then 500 ms may be too short even for a noncomplex scripts.
   • Some scripts are never done. They call themselves with some delay (setTimeout()) and work again and again and could possibly change the HTML every time they run. Seriously, every "Web 2.0" page does it. Even Stack Overflow. You could overwrite the most common methods used and consider the scripts that use them as completed, but ... you can't be sure.
   • What if the script does something other than changing the HTML? It could do thousands of things, not just some innerHTML fun.

3. There are tools to help you on this. Namely Progress Listeners together with nsIWebProgressListener and some others. The browser support for this, however, is horrible. Firefox began to try to support it from FF4 onwards (still evolving), IE has basic support in IE9.

And I guess I could come up with another flawed solution soon. The fact is - there's no definite answer on when to say "now the page is complete" because of the everlasting scripts doing their work. Pick the one that serves you best, but beware of its shortcomings.