Difficulties using provided driver type in serenity 1.1.21

[Dmitriy Grablyov]

Hi, John.

After upgrading to serenity core 1.1.21 I've noticed that tests using provided driver type are failing.

I tried to debug and unfortunately cannot give the full information, but here is what I found:

I'm using Serenity-Jbehave and custom driver at story level - by setting tag @driver remote in Meta block

- in ThucydidesWebdriverManager there is a method getThreadLocalWebDriver(final Configuration configuration, final WebDriverFactory webDriverFactory, final String driver) 

while debugging I've noticed that at story initialization this method is called with driver="provided" parameter, but after getSessionId call, this  method is called with driver="remote" and that is the reason of my tests failing, because serenity cannot find created instance of remote driver, tries to initialize it and fails since remote webdriver configuration is not in my settings/

- comparing to the version 1.1.5 I found difference in how WebDriverFacade returns webdriver class.

In 1.1.5 

    public Class<? extends WebDriver>  getDriverClass() {

        return driverClass;

    }

In 1.1.21

    public Class<? extends WebDriver>  getDriverClass() {

        if (driverClass.isAssignableFrom(SupportedWebDriver.PROVIDED.getWebdriverClass())) {

            return getProxiedDriver().getClass();

        }

        return driverClass;

    }

This means that after getSessionId call in ThucydidesWebDriverManager, serenity now thinks that it works not with a "provided" driver, but with "remote". As it cannot find "remote" in WebdriverInstances object it tries to create a new instance and fails since it is not configured properly.

Please, advise how can I avoid this situation or maybe there maybe some kind of fix applied to this.

I would be grateful for any help.

Best Regards,

Dmytro Grablov

[Dmitriy Grablyov]

From release notes this behavior starts fromhttps://github.com/serenity-bdd/serenity-core/releases/tag/v1.1.17

Having ProvidedDriver implement JavascriptExecutor should not be the correct way to fix THUCYDIDES-253. The method that checks if the driver is javascript enabled looks at the driver class returned from WebDriverFacade and in the case, it will see that ProvidedDriver implements JavascriptExecutor but when it tries to execute javascript on the proxied driver that does not necessarily have to implement JavascriptExecutor, then it will throw a method not found exception. This proposed fix checks if the driverclass in the WebDriverFacade is a provided driver, if it is, then the correct driver class it should look at is contained in the proxied driver.

[Dmitriy Grablyov]

Not having this problem anymore after 1.1.22-rc.4