How to use beforeGetText method of org.openqa.selenium.support.events.Interface WebDriverListener class

The driver is failing to properly terminate the sub processes created by Firefox like flash.

https://github.com/mozilla/geckodriver/issues/285

To avoid the dialogue box, you can set the environemnt variable XRE_NO_WINDOWS_CRASH_DIALOG to 1.

If you want to do the zoom in chrome (not with the css) you can use the API. For example:

driver.get('chrome://settings/')
driver.execute_script('chrome.settingsPrivate.setDefaultZoom(1.5);')
driver.get("https://www.google.co.uk/")

EDIT

In Java:

System.setProperty("webdriver.chrome.driver", /pathTo/chromeDriver);
ChromeDriver driver = new ChromeDriver();
driver.get("chrome://settings/");
driver.executeScript("chrome.settingsPrivate.setDefaultZoom(1.5);");
driver.get("https://www.google.co.uk/");

I feel like your misunderstanding the purposes of WebDriver, Grid and a multi-threaded environment.

Selenium WebDriver is just a test framework that kicks off tests onto a browser. It uses drivers such as geckodriver, and chromedriver to open (and close) browser instances and then hits those instances with actions.

Selenium Grid is a stand-alone server that will run your WebDriver tests remotely on a node and reports back. So if you wanted to use another machines resources to run your test-suite you would be able to do so. It also allows you to combine multiple machines resources by assigning each a node and Selenium Grid will distribute your tests evenly.

As far as your questions about multi-threading,

Is it recommended to use Grid over Selenium WebDriver in a multithreaded environment?

Grid is just a remote-runner of WebDriver. WebDriver is the test-framework. I assume your goal is to reduce your test-suite's run-time by running tests in parallel? Parallel testing can be done on your local machine using WebDriver or can be configured on a Selenium Grid. In my experience, I have gotten more lucky on my local machine than on Grid but both essentially face the same problem. The main danger for parallel testing using WebDriver is thread-safety. JUnit 4.7 onwards and Test-NG RELEASE allow for parallel testing. I highly suggest using Test-NG instead of JUnit for this purpose.

To prevent concurrency issues, your main goal will be to make all your shared resources isolated within each thread. A secondary goal is to limit the scope of all variables to its method. This can be done using a static instance of ThreadLocal It is also really useful to force the initializing of driver instances to be frozen in synchronized methods.

Creating Resources

public class DriverFactory {

    private static String grid = "http://localhost:4444/wd/hub";
    public static ThreadLocal<WebDriver> drivers = new ThreadLocal<WebDriver>();

    public static synchronized void newDriver() {
        ChromeOptions options = new ChromeOptions(); // Assuming Chrome use
            options.addArguments("--start-maximized");

        // USE THIS FOR LOCAL
        // tlDriver.set(new ChromeDriver(options));

        // USE THIS FOR GRID
        try {
            drivers.set(new RemoteWebDriver(new URL(grid),options));
        } catch (MalformedURLException e) {
            e.printStackTrace();
        }
    }

    public static synchronized WebDriver getDriver() {
        return drivers.get();
    }
}

Test Class

public class GoogleTest {
    @BeforeMethod
    public void setup() {
         DriverFactory.newDriver();
    }

    @Test
    public void test1() {
        WebDriver driver = DriverFactory.getDriver();
        driver.navigate().to("https:\\www.google.com");
        Assert.assertEquals(driver.getTitle(), "Google");
    }

    @Test
    public void test2() {
        WebDriver driver = DriverFactory.getDriver();
        driver.navigate().to("https:\\www.google.com");
        Assert.assertEquals(driver.getTitle(), "Google");
    }


    @AfterMethod
    public void tearDown() {
        WebDriver driver = DriverFactory.getDriver();
        driver.quit();
    }
}

TestNG.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<!-- thread-count should be = to maxSessions on your Grid -->
<suite name="Whatever" parallel="methods" thread-count="5">
  <test name="Sample">
    <classes>
      <class name="GoogleTest"/>
    </classes>
  </test>
</suite>

Source: Making your Tests Thread-Safe, Full Guide
Versions Used: TestNG 6.14.3, Selenium 3.11, Selenium Grid 3.14.3

Also, would Selenium Grid take responsibility of cleaning any stale browser instances in its nodes (out of the box)?

Selenium Grid has timeout and a browserTimeout features to free up nodes and close browser instances. Although in my experience I would implore you to control any expected timeouts in your test-cases and have WebDriver close the browser instance, not Selenium Grid. You really want to prevent this from happening and eliminate all causes of un-expected hanging. Test-suites are designed to be quick feedback and are only useful if failures are indicative of an actual failure, not just a dirty test-suite. Also stale nodes/browsers can force you to have to constantly reset your grid + nodes which is a major detriment.

I'm sure Florent B's solutions are viable, but for retro-fitting an old test, I found that zoonabar's solution posted to this duplicate question is easier to implement, takes considerably less code, and requires no special preparation of the test box. It also seems that it would be easier to follow for new developers looking at the code.

In short: visiting any URL with credentials before visiting the URL under test (without credentials) will cause the browser to remember the credentials.

goTo("http://user:password@localhost"); // Caches auth, but page itself is blocked
goTo("http://localhost"); // Uses cached auth, page renders fine
// Continue test as normal

This may feel like a vulnerability in the browser which will be patched, but I think this is unlikely; the restriction has been imposed to avoid phishing risks (where the username chosen looks like a domain, e.g. "http://google.com:long-token-here-which-makes-the-real-domain-disappear@example.com/"), and this workaround for setting credentials doesn't pose the same risk.

See zoonabar's answer

scrollIntoView

The DOM method scrollIntoView only scrolls the element into view. If scrollIntoView cannot scroll the element into view, it will just fail silently.I added an invisible element to the start of body and called scrollIntoView on it. Nothing scrolled but there was no error. Note that you have more control on how the element is scrolled with scrollIntoView than with moveToElement. Selenium is only interested in bringing the element into view so that the mouse can be placed on it. It does not give you any say in how it is going to do it. scrollIntoView however allows you, for instance, to specify whether you want the top or bottom of the element to be align with its scrollable ancestor. (See here for the details.)

moveToElement

The Selenium method moveToElement does two things: it scrolls the element into view and moves the mouse on top of the element. I've also tested it with elements that cannot be scrolled or moved to because they have no coordinates on screen and got no error here either.

Choosing One

I default to using moveToElement, with the following exceptions:

• If you do not want to affect at all where Selenium has placed the mouse but you want to scroll something into view (a bit strange... but possible), then you should use scrollIntoView.

• If you need to scroll an element with the kind of control that scrollIntoView gives you (like the alignment option I mentioned above), then you have to use it rather than moveToElement.

• There are cases where trying to simulate user behavior through Selenium's commands is not possible or is very expensive to do by sending a series of Selenium commands. (Each command is a round-trip to the network. When the testing server somewhere across the Internet, it adds up.) In such cases, I use Selenium's executeScript. In such case, it can be advantageous to use scrollIntoView in the script being executed, rather then end the script, create an Action to perform the scroll, and finish the whole operation with another executeScript.

For anyone interested, I solved this in the following ways:

1) I was originally testing this on OSX with Firefox 17 and Selenium 2.28/29, but figured out it only works (at least for me) on Windows with Firefox 18 and Selenium 2.29

2) interacting with SVGs with the standard:

driver.findElement(By.xpath(YOUR XPATH)).click();

doesn't work. You need to use Actions.

3) to interact with SVG objects, the following XPath works:

"/*[name()='svg']/*[name()='SVG OBJECT']";

The SVG object being anything under the SVG element (e.g. circle, rect, text, etc).

An example of clicking an SVG object:

WebElement svgObject = driver.findElement(By.xpath(YOUR XPATH));
Actions builder = new Actions(driver);
builder.click(svgObject).build().perform();

Note: you need to call the path inside the click() function; using:

moveToElement(YOUR XPATH).click().build().perform();

doesn't work.

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/

If you are on TestNg then to fail test case use below thow

Assert.fail();

or

Assert.fail("Write your custom error message");

Reporter.log() is for logging, it will not fail your test case.

Easiest solution would be, add the below lines in surefire plugin.

<suiteXmlFiles>
    <!-- pass testng.xml files as argument from command line -->
    <suiteXmlFile>${suiteXmlFile}</suiteXmlFile>
</suiteXmlFiles>

And run your xml file as below,

mvn clean test -Dsurefire.suiteXmlFiles=/path/to/testng.xml