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

The reason why .//g expression does not find the desired g elements is because of the namespaces. Your svg element has the default namespace defined as:

xmlns="http://www.w3.org/2000/svg"

Which means that the g child elements actually have svg:g names.

You can either account for the namespace:

.//svg:g

Or, ignore the namespace with local-name():

.//*[local-name() = 'g']

The problem is in the XPATH of the Product locators.

Below xpath expression in selenium means you are looking for a matching element which CAN BE ANYWHERE in document. Not relative to the parent as you are thinking!!

//div[@class='url']/a

This is why it always returns the same first element.

So, in order to make it relative to the parent element it should be as given below. (just a . before //)

public final static String URL_PATTERN = ".//div[@class='url']/a";
public final static String TITLE_PATTERN = ".//div[@class='title']";

Now you make it search for matching child element relative to the parent.

XPATH in selenium works as given below.

/a/b/c   --> Absolute - from the root

//a/b    --> Matching element which can be anywhere in the document (even outside the parent).

.//a/b   --> Matching element inside the given parent

The page contains anchors with a javascript href:

<a href="javascript:..." 

It does not make sense to test these links, therefore filter them as below code snippet:

String href = listOfElements.get(1).getAttribute("href");
if ((href != null) && !href.startsWith("javascript")) {
    int responseCode=getResponseCode(href);
    log.info("Response code of element at index 1 is:: " + responseCode);
}

It depends.

When using a static field, there is only a single instance of that field in the JVM. It refers to one specific address in memory. Unlike the field of an object which refers to a field of a specific object and for each object there is a unique address in memory for that field.

When using a ThreadLocal each thread has its own instance of the variable.

So by using static WebDriver driver you have exactly one webdriver for all tests and all threads. By using static ThreadLocal<WebDriver> driver you have exactly one webdriver for each thread, effectively sharing the webdriver between scenarios that are executed on that thread.

When executing tests in parallel there are multiple threads executing scenarios so a single webdriver would be a problem. Scenarios running in parallel would make the webdriver do different things at the same time or they'd have to wait for the webdriver to be available, making them effectively run serially again.

So if a webdriver is to be shared between scenarios and if those scenarios run in parallel you have to use a ThreadLocal.

However it appears that are unfamiliar with programming concurrent systems. So you may want to consider a different approach. Rather then sharing the webdriver between scenarios, consider starting a new webdriver in each scenario instead. This is much safer and from a test perspective much cleaner because each scenario starts without any state from the previous scenario.

This means you now have the problem of sharing information between steps. You were using a static field to share to share the webdriver. But you can't use use static fields because there are now multiple threads running.

To solve this problem Cucumber supports dependency injection. The easiest to use is probably cucumber-pico. When using dependency injection cucumber will instantiate each step definition class for each scenario with a isolated set of dependencies.

    <dependency>
        <groupId>io.cucumber</groupId>
        <artifactId>cucumber-picocontainer</artifactId>
        <version>${cucumber.version}</version>
        <scope>test</scope>
    </dependency>

So for example when your step definitions depend on a WebDriverFactory, cucumber will instantiate a WebDriverFactory for you and instantiate both StepDefinition and OtherStepDefinition with the same factory.

public class StepDefinition {

    private final WebDriverFactory webdriverFactory;

    public StepDefinitions(WebDriverFactory webdriverFactory) {
        this.webdriverFactory = webdriverFactory;
    }

    @Given("I do a thing with a webdriver")
    public void useTheWebDriver() {
        // get the webdriver from the factory and use it
    }

}

public class OtherStepDefinition {

    private final WebDriverFactory webdriverFactory; // Same instance as in StepDefinition

    public OtherStepDefinition(WebDriverFactory webdriverFactory) {
        this.webdriverFactory = webdriverFactory; 
    }

    @Given("I do another thing with a webdriver")
    public void useTheWebDriver() {
        // get the webdriver from the factory and use it
    }

}

Then in the web driver factory you keep a reference to the webdriver for use in both step definitions.

public class WebDriverFactory implements Startable {

    private WebDriver driver;

    public setDriver(String browser) {
        // create the web driver here 
    }

    public static synchronized WebDriver getDriver(){
        return driver;
    }

    public void start() { 
      // do nothing
    } 
    
    public void stop() { 
       // stop web driver if it was created
    } 
}

What about this ?

WebElement emailElement = driver.findElement(By.id("email"));
emailElement.sendKeys("ABCDEFG@g.com");

WebElement usernameElement = driver.findElement(By.id("username"));
usernameElement.click(); // Here, autocomplete is done

String userName = usernameElement.getText(); // get the value
assertEquals("ABCDEFG@g.com", userName);

If you want to send the TAB key with selenium, you can do that :

emailElement.sendKeys(Keys.TAB);

All special keys are available here

I will provide you code in Python for this. I think it's easy to translate to Java:

def scroll_down(self):
    """A method for scrolling the page."""

    # Get scroll height.
    last_height = self.driver.execute_script("return document.body.scrollHeight")

    while True:

        # Scroll down to the bottom.
        self.driver.execute_script("window.scrollTo(0, document.body.scrollHeight);")

        # Wait to load the page.
        time.sleep(2)

        # Calculate new scroll height and compare with last scroll height.
        new_height = self.driver.execute_script("return document.body.scrollHeight")

        if new_height == last_height:

            break

        last_height = new_height

Hope it helps you!

Webdriver utilizes a browser's native support for mapping the DOM element to WebElement object using id/xpath etc.

The JavascriptExecutor.executeScript executes an external script in the context of the currently selected browser window. (similar to an augmented browsing tool like grease monkey, if you ever used), and in case the script returns any DOM element its converted into WebElement object.

One can also say, the click simulated by WebDriver on a browser is similar to what actual user do as compared to one invoked using javascript.

In reality, with WebDriver not all the events can be automated flawlessly with all the web browsers, in fact with different versions of the same Web browser also. (i.e. different version of IE, FF etc behave differently). Still WebDriver is the near best tool available for this.

Once (~4 years back) on a certain version of IE we observed that we can't send right click or may be hover mouse on generated menu links, so we used js to simulate that, which performed very much browser independent way. so you can now conclude what executing external javascript can be good for.

Also, there are automated web testing frameworks which use javascript for everything instead of browser's native support. e.g. :http://en.wikipedia.org/wiki/Sahi_%28software%29

Ref:

• #executeScript%28java.lang.String,%20java.lang.Object...%29
• #findElement%28org.openqa.selenium.By%29

Create a inner class that implements Runnable and call it from a new Thread in com.util.SeleneseTestCase run() method. Something like this:

class YourTestCase extends SeleneseTestCase {
    public class MyRunnable implements Runnable {
        public void run() {
            // Do your have work here
        }
    }

    public void testMethodToExecuteInThread() {
        MyRunnable r = new MyRunnable();
        Thread t = new Thread(r);
        t.start();
    }
}

Update to use outside YourTestCase class

To run an inner class from another class you would need to make it public and then from the outer class execute this:

YourTestCase testCase = new YourTestCase();
YourTestCase.MyRunnable r = testCase.new MyRunnable();

But if you don't need to call it from inside your test case you'd better go with a normal class, make MyRunnable a public class without being in YourTestCase.

Hope it helps.

LE: I see quite a lot of people are interested in the full-page screenshot, so I thought I might update the answer with some positives (silver bullets).

There are quite a handful of web testing frameworks that can (with minimal setup & effort) produce a full-page screenshot. I come from a NodeJS testing environment, so I can only vouch the following: WebdriverIO & Google's Puppeteer.

If anyone is interested in an easy way to do it with WebdriverIO, check this answer.

Short answer is NO, YOU CANNOT, if you're only using Selenium (detailed reason bellow). But, what you can do is make the most out of your device's(monitor) viewport.

So, start your browser instance (driver) using ChromeOptions(), which is the method for setting ChromeDriver-specific capabilities. We can do the following:

• maximize the window (using the --start-maximized switch);
• go full-screen (F11-key on Windows, Control+Cmd+F on Mac, using the --start-fullscreen switch).
• Note: complete list of Chrome command-line-switches can be found here.

Your code should look like this:

// Setting your Chrome options (Desired capabilities)
ChromeOptions options = new ChromeOptions();
options.add_argument('--start-maximized');
options.add_argument('--start-fullscreen');

// Creating a driver instance with the previous capabilities
WebDriver driver = new ChromeDriver(options);

// Load page & take screenshot of full-screen page
driver.get("http://google.com");
File scrFile = ((TakesScreenshot)driver).getScreenshotAs(OutputType.FILE);

Now regarding the full page problem, all drivers (chromedriver, geckodriver, IEDriver, EdgeDriver, etc.) are implementing the WebDriver W3C standard. Thus, they are dependent on the way the WebDriver team wants to expose the functionality of different features, in our case, 'Take Screenshot'.

If you read the definition, it clearly states the following:

The Take Screenshot command takes a screenshot of the top-level browsing context’s VIEWPORT.

Legacy-wise, some drivers were able to produce a full-page screenshot (read more about it here), like the old FirefoxDriver, IEDriver, etc. That is no longer the case as they now all implement (to the letter) the WebDriver W3C standard.