Selenium 4.0 that is W3C compliant is coming, are you ready?
We still need to do a lot of scrambling to get all of the correct code together.
But I will do my best to guide you through all of the problems that you might face with the .NET bindings
It gets better:
I will continue to update this post with the latest research and code samples so that you are ready when it comes time to make the switch.
Code and release notes
If you want a bunch of the code samples that I created, those are here
Also, the full release notes from Jim Evans are here
If you want to try out the 4.0.0-alpha01 version of Selenium, get it from Nuget by running this command Selenium.WebDriver -Version 4.0.0-alpha01
Deprecation of DesiredCapabilities
If you want to work with a RemoteWebDriver to use the grid or a service like Sauce Labs, Browser Stack, Appium…
DesiredCapabilities are gone.
You have to use browser specific capabilities like ChromeOptions, SafariOptions and so on…
Here are some code samples of new, working capabilities:
options.AddAdditionalCapability deprecated
This is no longer valid:
options.AddAdditionalCapability("sauce:options", sauceOptions);
chromeOptions.AddAdditionalCapability("sauce:options", sauceOptions, true);
Replace with:
chromeOptions.AddAdditionalOption("sauce:options", sauceOptions);
ExpectedConditions and PageFactory moved to different package
This should come as no surprise since this has been known since WebDriver 3.11. Regardless, I tackle these issues here.
Working with ChromeOptions
Here’s a working code example using ChromeOptions:
AcceptInsecureCertificates in Options
Don’t use AcceptInsecureCertificates on IE, Edge, Safari as those browsers do not allow insecure certificates.
SafariOptions safariOptions = new SafariOptions
{
BrowserVersion = "12.0",
PlatformName = "macOS 10.13"
//AcceptInsecureCertificates = true Don't use this as Safari doesn't support Insecure certs
};
Added support for opening new browser windows
Jim Evans summarized it best:
The method creates a new browser tab/window and switches to it. As an argument, the method takes a type hint to indicate what type of browser context the user wants (a tab or a window).
Example usage:
driver.SwitchTo().NewWindow(WindowType.Tab);
Note carefully, however, this type hint is only a suggestion. If a browser
Jim Evans, https://github.com/SeleniumHQ/selenium/blob/master/dotnet/CHANGELOG
driver does not support creating new top-level browsers of the type desired by the user, it will still create the new top-level browser using whatever type it does support. This is perfectly compliant with the specification language for this command. As a concrete example, at the time of this commit, executing the above sample code against the IE driver will create a new top-level browser context, but as a window, not a tab, in spite of the fact that a new tab was explicitly requested. Even though the browser itself supports creation of new tabs, the driver does not. This will not be considered a valid bug, and issue reports claiming it is so will be summarily closed, possibly without comment.
Could you please clarify what is the difference between using Selenium.WebDriver.ChromeDriver from nuget package when comparing to download the webDriver on Selenium website and put the .exe available on the a path inside the project?
Both end up with the same output, a .exe that you can use to run Chrome. The question is do you want to maintain the .exe yourself, manually? Or do you want to maintain the .exe version through Nuget.