-
Notifications
You must be signed in to change notification settings - Fork 758
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specify a configurator type when using the v3 equivalent to CollectionBehaviorAttribute #2881
Comments
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 |
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. |
I would like to be able to configure MaxParallelThreads etc programatically from environment variables or Environment.ProcessorCount which cannot be expressed as attribute parameters.
The text was updated successfully, but these errors were encountered: