Hi Yang -

The NCrunch implementation needs to follow the standard approach as closely as possible, so I'm afraid that overriding NUnit behaviour in this instance is probably not the best long term approach for the product. NCrunch itself actually doesn't execute the NUnit tests itself - it integrates with NUnit and instructs the framework to execute tests on its behalf. This is a very different approach to, say, the NCrunch MSTest runner, which is actually a fully custom built test runner designed to behave as similarly to the normal MSTest runner as possible.

The advantage of relying on the NUnit framework itself to execute the tests is that if Charlie were to implement the behaviour you've described inside NUnit itself (i.e. perhaps as an optional feature), then NCrunch should automatically inherit the behaviour and be able to execute tests in the same way.

NCrunch's Xunit support has come a very long way since its early days. Although the test runner still relies on Gallio for the Xunit integration, many of the holes have now been resolved and I would recommend giving the framework another try to see how it performs. Right now the Xunit developers are busy working on V2 of Xunit, including a whole new backwards compatible API for tools such as NCrunch to integrate with. It isn't clear yet when this version of Xunit will be available, but I'm hoping to introduce direct support for this API shortly after it is fully released (therefore by-passing the Gallio integration). This means that if you do experience any problems with the Xunit integration, then there's a good chance they'll be fixed very soon and performance will likely also be improved.