Hi, thanks for sharing this problem.

As you've deducted, this problem is being caused by NCrunch's timeout enforcement. As of now, NCrunch's enforcement under .NET Framework involves executing Thread.Abort on the thread responsible for executing the test. It looks like when NUnit runs an async test, there is no way to reliably establish which thread is being used for the test execution from outside of NUnit, so NCrunch is making its best guess and is aborting the wrong thread. This leaves the test to keep running, while the thread responsible for managing the execution disappears, resulting in a hung task runner.

I don't think there is a simple solution to this problem. We will need to rethink the way that timeouts are enforced for async tests.

To work around this, you'll need to do one of the following:
- Ensure you specify an NUnit 'Timeout' attribute with a sensible timeout for the test
- Set NCrunch's default timeout to something high enough that it won't be enforced for this test
- Avoid using NUnit async tests

This is a very sensible workaround. Ideally having the test framework implementing the timeouts is always better, though test frameworks aren't really designed to use them in a blanket manner. The last time I checked, NUnit also wouldn't enforce timeouts under .NET Core (because Thread.Abort doesn't exist there), so there are some other considerations. Probably we'll go with enforcing all timeouts using Process.Kill instead, since this is much more reliable, even though it does have its own pitfalls.

I was, admittedly, concerned about this. NCrunch interprets the timeout values as fed to it by NUnit, which in turn parses the attributes itself. For the timeout attribute to work correctly at assembly level, NUnit itself would need to support it there. Interestly, the attribute itself is marked as being applicable at assembly level, so I wonder if this has always been an intention for NUnit and maybe it was never implemented.

We're still looking at options for revising NCrunch's timeout enforcement, so it's my hope that from 3.13 onwards you won't need to do this. Specifying TimeoutAttribute on each long running async test is a messy but still effective workaround to this problem.

Sorry, it looks like I was wrong.

NCrunch is inferring timeouts using the framework attributes itself, so it won't matter what NUnit reports. This isn't an NUnit problem.

The infrastructure here was built back in 2010, when NUnit didn't have an API and the whole integration was different. You'll need to use the Timeout attributes at either fixture or test level to work around this problem until it is fixed in NCrunch.

Thanks for flagging this back up. Somehow, I forgot to task this up and it was never fixed. Consequently:

- NUnit will still enforce these timeouts at test-level but NCrunch won't extract useful error information
- At fixture level (i.e. OneTimeSetup) these aren't enforced at all

I've tasked this up properly now with a goal to fixing it in the new year. For the time being, I recommend declaring the NCrunch.Framework.TimeoutAttribute next to the NUnit one, as this one can also be declared at assembly level and it will be correctly detected by NCrunch.

Hi, I think we did end up fixing this earlier this year. Most likely the fix is included in the latest release on the download page, if not, we're hoping to push a new build later this month. Please let me know if neither build resolves the issue.