How to use GeckoDriverService class of org.openqa.selenium.firefox package

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.

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.

The WebElementWait class as metioned above:

package org.openqa.selenium.support.ui;

import java.util.concurrent.TimeUnit;

import org.openqa.selenium.NotFoundException;
import org.openqa.selenium.WebElement;

public class WebElementWait  extends FluentWait<WebElement>  {
    public final static long DEFAULT_SLEEP_TIMEOUT = 500;

      public WebElementWait(WebElement element, long timeOutInSeconds) {
            this(element, new SystemClock(), Sleeper.SYSTEM_SLEEPER, timeOutInSeconds, DEFAULT_SLEEP_TIMEOUT);
      }

      public WebElementWait(WebElement element, long timeOutInSeconds, long sleepInMillis) {
            this(element, new SystemClock(), Sleeper.SYSTEM_SLEEPER, timeOutInSeconds, sleepInMillis);
      }

      protected WebElementWait(WebElement element, Clock clock, Sleeper sleeper, long timeOutInSeconds,
              long sleepTimeOut) {
            super(element, clock, sleeper);
            withTimeout(timeOutInSeconds, TimeUnit.SECONDS);
            pollingEvery(sleepTimeOut, TimeUnit.MILLISECONDS);
            ignoring(NotFoundException.class);
      }

}

It's the same as WebDriverWait, except that the WebDriver argument is replaced with WebElement.

Then, the isValid method:

//import com.google.common.base.Function;
    //import org.openqa.selenium.TimeoutException;

public boolean isValid(WebElement e) {
    try {
        WebElementWait wait = new WebElementWait(e, 1);
        //@SuppressWarnings("unused")
        //WebElement icon = 
        wait.until(new Function<WebElement, WebElement>() {
                    public WebElement apply(WebElement d) {
                        return d.findElement(By
                                .xpath("./following-sibling::div[class='invalid-icon']"));
                    }
                });
        return false;
    } catch (TimeoutException exception) {
        return true;
    }
}

WebDriver and Selenium are perfectly suited for production environnement. I use them quite extensively for 2 years now on a multi-machines/multi-datacenters distributed grid and had absolutely no performance nor stability problems we couldn't have coped with.

Our preferred driver is the Firefox one (heavier than HTMLUnit, and harder to configure), and we had to tweak the grid to understand how many instances we can run. Our maximum for stability was 1 per core

Our selenium/webdriver instances have run 24/7 for 2 years now (1 year with selenium 1, and the other migrating selenium 2/ WebDriver incrementally) and with an appropriate monitoring (you should monitor Memory Usage/CPU Usage) and a bunch of load testing, we had reached the good level where we have experienced several monthes without restarting a process

We've used HTMLUnit extensively too, and are equally satisfied with this library

The essential point of my post is : YES, these library are production-ready. But, as all production software, you'll have to benchmark their use to find the appropriate configuration for the optimal stability. I recommend you to use the Selenium Grid in production, which is a great way to parallelize process

First of all you need to import the proper drivers into the project/class.

like

import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.ie.InternetExplorerDriver;

etc.

The you need to create new Webdrivers for the broswer you need.

like

WebDriver driver = new FirefoxDriver();
WebDriver driver = new InternetExplorerDriver();
WebDriver driver = new ChromerDriver();

etc for each browser.

NOTE: It is tough to use different browsers/drivers in a single test. Either you may use similar tests for each browser and maintain a test-suite (i.e. use one driver and import in a test and maintain similar test for other browsers) or you can use some config files or excel to pick up which browser you want the test to run. You might like to explore http://htmlunit.sourceforge.net/ for headless testing.

And information about OperaDriver can be found here: - https://github.com/operasoftware/operadriver/

There are 2 way to do this that will give you meaningful data.

1. Use Browsermob Proxy with Selenium. This is an example in python but its pretty much the same in Java

   from browsermobproxy import Server
   server = Server("path/to/browsermob-proxy")
   server.start()
   proxy = server.create_proxy()
   
   from selenium import webdriver
   profile  = webdriver.FirefoxProfile()
   profile.set_proxy(proxy.selenium_proxy())
   driver = webdriver.Firefox(firefox_profile=profile)
   
   proxy.new_har("google")
   driver.get("http://www.google.co.uk")
   proxy.har # returns a HAR JSON blob
   
   proxy.stop()
   driver.quit()
   

The HAR file that is returned from proxy.har, which is just a JSON blob, will give you the information that you need. I blogged about it earlier this year

2. The other approach is to use the navigations timings spec available in modern browsers. All that you need to do is execute some javaScript and you will get details of page load etc.

   ((JavascriptExecutor)driver).executeScript("var performance = window.performance || {};" + 
               "var timings = performance.timing || {};"+
               "return timings;");
   
   /* The hashmap returned will contain something like the following.
    * The values are in milliseconds since 1/1/1970
    *
    * connectEnd: 1280867925716
    * connectStart: 1280867925687
    * domainLookupEnd: 1280867925687
    * domainLookupStart: 1280867925687
    * fetchStart: 1280867925685
    * legacyNavigationStart: 1280867926028
    * loadEventEnd: 1280867926262
    * loadEventStart: 1280867926155
    * navigationStart: 1280867925685
    * redirectEnd: 0
    * redirectStart: 0
    * requestEnd: 1280867925716
    * requestStart: 1280867925716
    * responseEnd: 1280867925940
    * responseStart: 1280867925919
    * unloadEventEnd: 1280867925940
    */ 
   

In a word, no. It's not possible using the Selenium WebDriver API. This has been discussed ad nauseam in the issue tracker for the project, and the feature will not be added to the API.

The getSize method returns the rendered web element size and not the physical size of an image. If your goal is to get the intrinsic height and width, then you could try to get the naturalWidth and naturalHeight properties:

WebDriver driver = new FirefoxDriver();
WebDriverWait wait = new WebDriverWait(driver, 20);
driver.get("http://stackoverflow.com");

// get the intrinsic size with the getAttribute method
WebElement ele = driver.findElement(By.cssSelector("img"));
String naturalWidth = ele.getAttribute("naturalWidth");
String naturalHeight = ele.getAttribute("naturalHeight");

// get the intrinsic size with a piece of Javascript
ArrayList result = (ArrayList)((JavascriptExecutor) driver).executeScript(
        "return [arguments[0].naturalWidth, arguments[0].naturalHeight];", ele);
Long naturalWidth2 = (Long)result.get(0);
Long naturalHeight2 = (Long)result.get(1);

It is actually possible to scroll automatically to element. Although this is not a good solution in this case (there must be a way to get it working without scrolling) I will post it as a workaround. I hope someone will come up with better idea...

public void scrollAndClick(By by)
{
   WebElement element = driver.findElement(by);
   int elementPosition = element.getLocation().getY();
   String js = String.format("window.scroll(0, %s)", elementPosition);
   ((JavascriptExecutor)driver).executeScript(js);
   element.click();
}