In the past I've occasionally announced something "coming soon" that never saw the light of day, and because of this I've greatly reduced the number of times that I mention any ideas that are still in the vaporware stage.  This time though I just wanted to get it out there.

I mentioned here that Unit Testing was a big chance to save developers time using concurrency.  I actually downloaded the NUnit source immediately after posting that and started looking at what it would take to get NUnit to run tests concurrently.  It's my current opinion, though I reserve the right to change my position later, that NUnit is an over engineered mess.  It uses some interesting combinations of patterns that ultimately makes an amazingly deep and hard to follow pipeline for test execution and result reporting.  The path for running a test suite goes something like this:

1. Click "Run tests" button
2. GUITestRunner
3. ... passes to ThreadedTestRunnger (so the UI remains responsive)
4. ... passes to ProxyTestRunner
5. ... crosses a remoting boundary for some reason
6. ... RemoteTestRunner
7. ... passes to SimpleTestRunner
8. Foreach unit test, execute, collect results...
9. ... pass the results back across the remoting boundary to display in the GUI

I'm sure I'm missing at least one step in there.  The first trial of making SimpleTestRunner execute the tests in Parallel failed because there seems to be some bizarre hook in the test result capturing scheme that didn't like being threaded.  I will either track down this issue, create my own XTestRunner implementation, or blow an evening making my own unit test scheme that can run in parallel.  If I can then get TestDriven and NCover to hook into that, life would be good indeed.