[🚀 Request] Expose more configuration for selenium-webdriver ServiceBuilder

[bmingles]

Describe the request

The instantiation of the selenium-webdriver/chrome ServiceBuilder is currently encapsulated in the VSBrowser.start function. It would be nice to expose some of its configuration options, specifically ones related to logging.

For example, the setStdio and enableVerboseLogging methods can be helpful for diagnosing root causes of errors that currently get swallowed:

const serviceBuilder = new ServiceBuilder(chromeDriverBinaryPath);

// Setting this allows logging to make it to stdio of process running tests
serviceBuilder.setStdio('inherit');

// Provides more detailed logging if needed
serviceBuilder.enableVerboseLogging();

this._driver = await new page_objects_1.Builder()
  .setChromeService(serviceBuilder)
  .forBrowser(page_objects_1.Browser.CHROME)
  .setChromeOptions(options)
  .build();

I'm not familiar enough with the architecture to suggest how these might best be exposed, only that having some way to configure the ServiceBuilder would be helpful.

Usage

Enabling more verbose logging was key to being able to identify the root causes of this issue: https://github.com/redhat-developer/vscode-extension-tester/issues/1767

[alagiribuddhar]

It would be helpful if chrome driver builder options were configurable both via CLI and via Extester API. In chrome driver we can run driver in headless mode. For running Extester in CI/CD pipeline headless mode would offer better performance than xvfb. Is there any time line when this feature can be expected.

[djelinek]

It would be helpful if chrome driver builder options were configurable both via CLI and via Extester API. In chrome driver we can run driver in headless mode. For running Extester in CI/CD pipeline headless mode would offer better performance than xvfb. Is there any time line when this feature can be expected.

I agree we can expose more options to configure for selenium-webdriver

regarding headless mode, afaik it won't be working for VS Code e2e testing because you cannot run UI tests in headless mode for Electron app

[ssbarnea]

@djelinek Regarding headless, I think is more about possible use of xvfb to use a different screen the the current one, so you can run the tests in background locally? I would find this very useful for testing locally.

Would this be possible? So far I only used xvfb to enable CI execution, but I do not see why the same concept would not apply for running locally.

[djelinek]

this is for sure possible locally. But only on Linux, so if you will use eg. tigervnc or xvfb locally then you can just start server locally and run ´DISPLAY=:XY npm run ui-test´. So yes, on linux you can go kinda "headless"

[igorgiumellizup]

this is for sure possible locally. But only on Linux, so if you will use eg. tigervnc or xvfb locally then you can just start server locally and run ´DISPLAY=:XY npm run ui-test´. So yes, on linux you can go kinda "headless"

Hi. Does this work on GitHub Actions on a Linux image? If not, is there a way to run ExTester tests on GA?

[djelinek]

this is for sure possible locally. But only on Linux, so if you will use eg. tigervnc or xvfb locally then you can just start server locally and run ´DISPLAY=:XY npm run ui-test´. So yes, on linux you can go kinda "headless"

Hi. Does this work on GitHub Actions on a Linux image? If not, is there a way to run ExTester tests on GA?

afaik to run UI tests on GH actions linux runner it is an expected way to execute with virtual display, eg.:

xvfb-run --auto-servernum --server-args='-screen 0 1920x1080x24' npm run ui-test