in the past 15 minutes the NCrunch engine stalled two times.
There were several processes in the processing queue with status "Processing". However, they never finished. I waited over five minutes both times. Those tests normally finished in seconds.
I uploaded two bug reports for you to check:
http://rapidshare.com/files/2608707663/Report_StalledEngine.zip
http://rapidshare.com/files/2516578773/Report_StalledEngine2.zip
I just found out that it was actually one of my integration tests that was hanging because of a database lock that has not been released by a previous test.
It would be nice to have a fifth icon in the toolbar for "Show executing tests".
And maybe a way to cancel a specific test.
BTW: It seems to currently be impossible to see which test is really currently executing. I have 9 tests that have the status "Running", but only one of them can actually execute currently as they have all the same ExclusivlyUses attribute.
BTW: It looks like there is a problem with the timeout feature. I set the timeout to 6000 but still, no tests time out.
Database transactions/locks are a common cause of tests hanging - especially under parallel execution. I'm hoping to improve some of the mechanics around the test runner to make these situations easier to analyse and control, with much of what you've suggested already part of the plan for future features.
Right now NCrunch 'batches' faster running tests together to reduce the overhead of needing to process results from every independent test in real-time. This has certain performance advantages, but it's rather messy when you have fast running integration tests that are unstable (as you've described). The tests will still be executed sequentially when they exist as part of the same task, but visibility on what is happening is currently very limited.
The timeout itself is controlled by ThreadAbortExceptions that occur on the test runner thread. It's been found that in certain circumstances (particularly around database locks and transactions), ThreadAbortExceptions do not behave timely and the test often still waits for the lock to clear. I'm hoping to improve this in future with more vigorous enforcement (i.e. by terminating the entire test process).