Final Non-Parallelizable Test appears to record incorrect duration when TimeoutAttribute used

My test assembly runs with mainly parallel fixtures, via [assembly: Parallelizable(ParallelScope.Fixtures)]. There are approx 10,000 tests - within this, I have a couple of tests using TimeOutAttribute I’ve specifically marked the fixtures ParallelScope.None. The below is a minimum example of such a fixture.

[TestFixture, Parallelizable(ParallelScope.None)]
public class TestFixture
{
    [Test, Timeout(100)]
    public void ATest()
    {
    }
}

When running under NUnit Console, the final Non-Parallelizable Test appears to record an additional ~30 seconds in duration. (Even in the above situation, where the test is empty.) Hence the Timeout fails.

The extra time added to this test, appears to be within the console runner activity. I’m running a single assembly. When I remove the troublesome test, I see that the test-run recorded end-time is 30 seconds later than the end-time of the single test suite. With the bad test - the bad-test-end-time roughly matches test-run-end-time - but test-suite-end-time remains the same. Meaning the end time of the bad test is AFTER the end time of the assembly test-suite that contains it.

This bug DOESN’T appear with NUnitLite - where I’ve previously run these tests.

Some further specifics.

1. This only occurs when I have a mix of ParallelScope.Fixtures and ParallelScope.None. If I have all tests in parallel, or none in parallel, the per-test duration looks to be sensible.
2. The TimeoutAttribute appears key, without this, the test has a normal duration.
3. The overall (reported) test run duration remains constant, whether I use Timeout on the non-parallelizable test, and the test reports taking 30 seconds longer, or not. This makes me suspect a reporting issue, rather than a test-running issue.
4. In terms of the timeline, it appears that the ParallelScope.Fixtures tests are all running first, then the ‘none’ fixture is ran once those have completed. I’m unsure as to where the additional 30 seconds comes from.

Additionally, for some reason, the failed test isn’t reported in the console. This is the output I see - there’s no log of failed tests.

I’m suspicious there are two bugs here:

1. What is the console doing for an extra 30 seconds, after the completion of the test-suite run. (The console run also takes ~30 seconds longer than the NUnitLite run.)
2. Why is the ‘bad-test’ duration incorrect, and outside of the overall test suite run.

There’s probably more digging to do here, but only so much I can do at the moment. Appreciate any early thoughts as to what’s going on.

[CharliePoole]

In fact, it’s a worker event being handled by the dispatcher. As each worker finishes a task, the Idle event fires and the dispatcher checks to see if there is no more work in the shift. If not, it terminates the shift and either starts a new one or ends the run completely.

Basically, there are no special threads for either the dispatcher or the three different shifts. Everything happens on worker threads.

[ChrisMaddock]

Thanks Charlie - and thanks for the pre-emptive fix! 😄

I think I made some assumptions by the “Parallel shift ending” log message being posted from one specific worker thread. I assume in this case, that thread 16 was the ‘master worker’ or so, which decided when all the work was complete?