That makes it the safest setting when one is not sure whether the tests can run in parallel. A value of 0 (rather than 1) causes the framework to use an entirely different legacy dispatcher, which is completely incapable of parallelism. The actual value we usually use in the framework is 0, although it's possible that <0 works as well. OTOH, we generally assume that it is safe to run tests in one assembly in parallel with (usually) unrelated tests in another IIRC, the default of -1 is merely used in the code to indicate that no setting was specified. Without that promise, we don't even want to try. The reason for this is that the author of the tests, when using ParallelizableAttribute is promising that it is safe to run them in parallel. The setting can only limit parallelism or turn it off. NumberOfTestWorkers can't turn on parallelism if the attributes in the code don't call for it. The setting is the same as the Workers setting in the console, and it doesn't say there either ( Clarifying (even though Terje knows this already). If NumberOfTestWorkers is set to anything >0, and parallel is disabled in Test Explorer, it will write out a warning saying there are conflicting Thinking about this, this setting has been so for a very long time - but, shouldnt the no-parallell be 1, not 0 ? What is the difference between 0 and <0 ? However, the adapter picks the settings up, and if TestExplorer is set to "no parallel", AND the NumberOfTestWorkers is default - which is -1 meaning all, it will automatically set the NumberOfTestWorkers to 0. This has nothing to do with the NUnit parallel mechanism, which needs to be controlled through NumberOfTestWorkers property in the runsettings file - if not done in code. The checkbox in Test Explorer only controls the VSTest parallell execution, which as you point out, only runs assemblies in parallel.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |