Can’t find RemoteWebDriver in WebDriverIO, now what?

Can’t find RemoteWebDriver in WebDriverIO, now what?

Reacties 0 reacties

My transistion from Java to WebDriverIO has been a pretty fun journey with some (minor) speedbumps along the way. My own issue sometimes is letting go of the Java way and embrace the teachings WebDriverIO 🙂

For example running tests with a SeleniumGrid. Bring on the RemoteWebDriver! 

WebDriver driver = new RemoteWebDriver("http://127.0.0.1:9515", 
      DesiredCapabilities.chrome());
driver.get("http://www.google.com");

Searched the interwebs for WebDriverIO RemoteWebDriver but nothing turned up. My search turned up enough documentation regarding WebDriverIO and SeleniumGrid so the capability (yes, pun intended) was there.

Since I had to do some experimenting myself to get everything up and running I decided to share my findings for any other J-peeps making the transition from Java to WebDriverIO.

To the config!

exports.config = {
    // see: https://github.com/webdriverio/webdriverio/issues/2262
    seleniumInstallArgs: { version: '3.4.0' },
    seleniumArgs: { version: '3.4.0' },

    specs: [
        './test/features/*.feature',
    ],
    // Patterns to exclude.
    exclude: [
        // 'path/to/excluded/files'
    ],
    host: "URL to your Selenium grid",
    port: "port to your Selenium grid",
    path: '/wd/hub',
    protocol: 'https',

The config file drives/starts the driver so it makes sence to specify a host and port here. The path and protocol complete the remote setup for running tests on a Selenium Grid. That’s it….

Embrace the way of the WebDriverIO, even when it’s hard to comprehend the simplicity for someone coming from WebDriver with Java.

WebDriver won’t click the checkbox in Chrome Headless, now what?

WebDriver won’t click the checkbox in Chrome Headless, now what?

Reacties 0 reacties

Chrome headless, love it! And usually it works like a charm, but this week we ran into a problem with the checkbox not being clicked in our headless runs. Tried every wait strategy I could think of but waiting was not the issue (for once 🙂 )

Tried to go the set attribute route but nope. No succes. Some kind of React mumbo jumbo going on.

The culprit!

 

Did some digging on the interwebs and found out other people are having this issue as well. Might even be a Chrome headless issue with nog fix being on the horizon. So only one thing left to do: Straight JS injection!

 

// React checkbox not clickable headless, direct JS injection required
browser.execute(function() {
    let elements = document.getElementsByClassName("checkbox__input");
    elements.item(0).click();
});

Luckly WebDriverIO lets you execute JS commands with the .execute command. Above I went the ByClassName route which returns a list with elements found but you can also go the ById route

// React checkbox not clickable headless, direct JS injection required
browser.execute(function() {
    document.getElementById("checkbox__input").click();
});

With the straight JS injection, the checkbox gets clicked, headless and in regular mode (with head?)

WebDriverIO tests fails inconsistently with a socket error, now what?

WebDriverIO tests fails inconsistently with a socket error, now what?

Reacties 0 reacties

Once in while my WebDriverIO test failed with a Java socket error, not everytime but it was still pretty enjoying! Especially when your test has to run in a CI/CD environment. One flakky test and the enitre credibilty of your test suite is at stake. I love WebDriverIO but I needed a fix.

Unfortuantly the error didn’t help me much

java.net.SocketException: Connection reset by peer
  Error: An unknown server-side error occurred while processing the command.
      at elementIdDisplayed("0.14703088915361828-3") - isVisible.js:71:55

So after roaming around on the interwebs I found this issue:

Selenium issue 5611

Good news, other people are having this issue. Bad news, at the time of writing this post the issue hasn’t been resolved. So I needed a work around.

After some more digging I found a 2 part solution

First downgrade to a Selenium Standalone version which doesn’t have the issue. This can be acchieved by setting the standalone version to 3.4 in the config file

exports.config = {
// see: https://github.com/webdriverio/webdriverio/issues/2262
seleniumInstallArgs: { version: '3.4.0' },
seleniumArgs: { version: '3.4.0' },
specs: [
'./test/features/*.feature',

This however is not enough. The previous, newer selenium version with the issue is still present in the node_modules folder. Now you can either delete all the folders using 

rm -rf node_modules

or only the selenium folder just make sure you do a 

npm install

after deletion and you are good to go!

PageFactory depricated, now what??

PageFactory depricated, now what??

Reacties 0 reacties

So one of the latest Selenium WebDriver releases depricated the PageFactory in C#. This kind of forces us to rethink our POM strategy. As somebody how has being doing the POM setup the same way for a few year now I really like this!

The “old” way:

@FindBy(css = "div[data-testid='theme']")
    private WebElement themePageButton;

public EditionPage(WebDriver driver){
    this.driver = driver;
    PageFactory.initElements(driver, this);
}

Calling the element in a method:

themePageButton.click();

So how do we still declare the element as a global variable with out using the FindBy annotation?

By to the rescue!

By themePageButtonLocator = By.cssSelector("div[data-testid='theme']");

public EditionPage(WebDriver driver){
    this.driver = driver;
}

We removed the PageFactory, the annotation and declared the By locator as a global By. We can now call the element in a method by using the By locator:

driver.findElement(themePageButtonLocator).click();

PageFactory.initElements() is gone, mission accomplished!