Possibility of using devtool protocol instead of chromedriver ?

[pillsilly]

Just curious

[christian-bromann]

Can you provide more context why you would like to use the devtools protocol? Technically I don't see a reason why this should not work.

[pillsilly]

Can you provide more context why you would like to use the devtools protocol? Technically I don't see a reason why this should not work.

Though wdio has done some work to hide driver protocol differences in API level, but not all of them could be done perfectly - in fact there are still many of them left to the user handle with
I know that's not wdio's fault, it's because of the natural difference between chrome driver and gecko driver and devtools.

Like the behavior of listening to alert,
Like getText/getHtml could return different result if the element contains some special characters (like /n, &nbsp),
Like browser log handling,
and so on and so on.

After many practices, it seems the simplest way could be to just use the same protocol for your product when testing it in different platform/browser -- even if you're using wdio.

Our app is tested in FF, Chrome and Electron
now it's kinda embarrassing that we have used devtool and Chrome and even Firefox,
for Electron which is chromium based we have no devtool path available yet.

For chrome and firefox even if devtool is used there can be still a lot of different behaviors
but
at least for chrome and chromium, in my limited experience, I could hardly remember anything difference when testing them with my app.

[goosewobbler]

Being honest I don't know what's involved here, whether it requires changes to this service and / or WDIO, or if it's just a support / WDIO usage issue.

[pillsilly]

I'm guessing to achieve what I want, modification towards electron service is needed while wdio change is relatively less needed (not sure)

for instance, some configuration entry might need to get exposed just as normal wdio conf
(that user could choose either the devtool or webdriver as the protocol to chromium which is held by electron)

then the lower implementation shall try to start electron with giving it the startup option remote-debugging-port,
so that electron could pass the remote-debugging-port to chromium which is required by devtool connectivity.
https://www.electronjs.org/docs/latest/api/command-line-switches#--remote-debugging-portport

just my naive thinking

[christian-bromann]

@pillsilly thanks for providing more input. I honestly would recommend not to rely on the devtools protocol. It is proprietary and can change between every Chrome version. The WebDriver protocol is better suited as it doesn't change and features are tested. If you need features that are only available in the devtools protocol I would just switch to it if necessary but do all other automation through WebDriver.

Again, given that Chromedriver also just uses the devtools protocol I assume it is possible to attach yourself to it. The service is currently starting the session via WebDriver. I am sure same is possible via DevTools. It would require to start the app with some additional parameter I assume. There could be a service option defining how to start the session. If you are interested implementing this feature, let us know.

[pillsilly]

Again, given that Chromedriver also just uses the devtools protocol I assume it is possible to attach yourself to it. The service is currently starting the session via WebDriver. I am sure same is possible via DevTools. It would require to start the app with some additional parameter I assume.

talking about that I had experience for similar work on other test stack. it was cucumber + protractor + wdio

protractor conf:

 chromeOptions: {
                args: [
                    `--remote-debugging-port=${remoteDebuggingPort}`,

cucumber hook

async function connectToWdi() {
    const session = await browser.driver.getSession();
    const wdiBrowser = await attach({
        options: {
            automationProtocol: 'devtools'
        },
        sessionId: session.getId(),
        capabilities: {
            browserName: 'chrome',
            'wdio:devtoolsOptions': {
                browserURL: `http://127.0.0.1:${remoteDebuggingPort}`
            }
        }
    });
    browserWdi = wdiBrowser;
   ...
}

it works well, under such configurations I am able to use browserWdi ( the browser instance from wdio) and browser (protractor's browser instance) simultaneously.

but in wdio I am not sure how to achieve similar thing because it doesn't seem like wdio provides an API like switchToProtocol in runtime or anything like that.

but anyway I would like to try when I have time , to see if I call the attach as I did in protractor's , what would happen.

but if you @christian-bromann or anyone has idea/info for how it could be possible (to let the devtool becomes my main driver of electron test undre wdio) it would be thankful