Specify a configurator type when using the v3 equivalent to CollectionBehaviorAttribute

[jcracknell]

I would like to be able to configure MaxParallelThreads etc programatically from environment variables or Environment.ProcessorCount which cannot be expressed as attribute parameters.

[bradwilson]

For v2 runners, we would expect you to be able to compute it ahead it time (with a bit of custom code) before invoking the unit tests and pass that number along on the command line or in a dynamically created configuration file. Trying to add an extensibility hook inside the unit tests is too late, because in v2 we need to make the execution environment decisions before the test code is run (or perhaps even loaded).

For v3 runners, we have added a new multiplier format for maxParallelThreads:

Also for v3, we could consider enhancing the kinds of things you can do during a customized entry point that would give you the opportunity to manipulate configuration before the test environment is created, but today this is only crudely available by manipulating the arguments that are passed to ConsoleRunner.Run(). A better usability experience would be nice in this scenario (maybe a stripped down version of the way configuration works today in ASP.NET Core apps).

[jcracknell]

Trying to add an extensibility hook inside the unit tests is too late, because in v2 we need to make the execution environment decisions before the test code is run (or perhaps even loaded).

I mean maybe for some environment decisions, but this doesn't seem to be strictly true as it's technically possible to achieve this with v2 now in a very roundabout way via TestFrameworkAttribute.

A custom entrypoint could also work, although my thought was to provide an easy way to override the default configuration behavior as opposed to having to rewire the entire test execution process a la TestFrameworkAttribute.