[🚀 Feature]: [dotnet] Revisit unit tests infrastructure

[nvborisenko]

Feature and motivation

Current situation is:

Usage example

Concerns:

• It could be one test project because Chrome/Edge/Firefox drivers live in one project supported by Selenium (like built-in classes).
• Default namespace in test project is OpenQA.Selenium when usually it should be OpenQA.Selenium.Tests. I don't understand why it is unusual.
• Avoid any static context (EnvironmentManager class) - it will allow to look at parallelization. My computer has 6/12 cores, I want to utilize all of them when running Selenium unit tests.

[RenderMichael]

I don't have much of the historical context surrounding the design decisions of the test projects. There are some clear reasons I see for a heavily configuration-based EnvironmentManager. For example, the EnvironmentManager.Instance property is accessible in the AssemblyFixture types.

At the same time, I see some room for optimization.

Notably, the above AssemblyFixture's one-time setup starts the web server and the remote server, but not the driver. The one-time teardown closes whatever driver may be opened, likely as a precaution. I fully believe we can move the "current driver" management to the test-side.

Rather than using appconfig.json (and all the Runfiles.Create() and runfiles.Rlocation ceremony surrounding that), we can give DriverTestFixture a method like so:

public abstract class DriverTestFixture
{
    public abstract IWebDriver CreateDriver();
}

I can experiment with some potential solutions.