title: How exactly do MbUnit's [Parallelizable] and DegreeOfParallelism work?
body: <p>I thought I understood how MbUnit's parallel test execution worked, but the behaviour I'm seeing differs sufficiently much from my expectation that I suspect I'm missing something!</p>
  
  <p>I have a set of UI tests that I wish to run concurrently. All of the tests are in the same assembly, split across three different namespaces. All of the tests are completely independent of one another, so I'd like all of them to be eligible for parallel execution. </p>
  
  <p>To that end, I put the following in the AssemblyInfo.cs:</p>
  
  <pre><code>[assembly: DegreeOfParallelism(8)]
  
  [assembly: Parallelizable(TestScope.All)]
  </code></pre>
  
  <p>My understanding was that this combination of assembly attributes should cause all of the tests to be considered <code>[Parallelizable]</code>, and that the test runner should use 8 threads during execution. My individual tests are marked with the <code>[Test]</code> attribute, and nothing else. None of them are data-driven.</p>
  
  <p>However, what I actually see is at most 5-6 threads being used, meaning that my test runs are taking longer than they should be. </p>
  
  <p>Am I missing something? Do I need to do anything else to ensure that all of my 8 threads are being used by the runner?</p>
  
  <p>N.B. The behaviour is the same irrespective of which runner I use. The GUI, command line and TD.Net runners all behave the same as described above, again leading me to think I've missed something.</p>
  
  <p><strong>EDIT:</strong> As pointed out in the comments, I'm running v3.1 of MbUnit (update 2 build 397). The <a href="http://www.gallio.org/api/index.aspx" rel="noreferrer">documentation</a> suggests that the assembly level <code>[parallelizable]</code> attribute is available, but it does also seem to reference v3.2 of the framework despite that not yet being available.</p>
  
  <p><strong>EDIT 2:</strong> To further clarify, the structure of my assembly is as follows:</p>
  
  <pre><code>assembly
  - namespace
     - fixture
        - tests (each carrying only the [Test] attribute)
     - fixture
        - tests (each carrying only the [Test] attribute)
  - namespace
     - fixture
        - tests (each carrying only the [Test] attribute)
     - fixture
        - tests (each carrying only the [Test] attribute)
  - namespace
     - fixture
        - tests (each carrying only the [Test] attribute)
     - fixture
        - tests (each carrying only the [Test] attribute)
  </code></pre>
  
  <p><strong>EDIT 3:</strong> OK, I've now noticed that if I only ever run one fixture at a time, the maximum number of tests running concurrently is always 8. As soon as I select multiple fixtures, it drops to either 5 or 6. If I take the contents of two fixtures (currently they contain 12 tests each) and drop them into the same fixture (for a total of 24 tests in that one fixture) that fixture will also always run 8 tests concurrently. </p>
  
  <p>This seems to show that it isn't an issue in the individual tests, but rather in how the assembly level attributes percolate down to the fixture, or how the test runner consumes those attributes. </p>
  
  <p>Additionally, I also observed (when running two fixtures) that once one of the two fixtures had been executed in its entirety, the runner starts to execute more tests concurrently when its back down to running only one fixture. For me right now, the first fixture gets done executing when there are 7 tests left to run in the second fixture. As soon as that happens, the number of tests running concurrently jumps up from the previous 5 or 6 to the maximum available of 7.</p>