Hi Max,

Always good to hear from kiwis in other parts of the world, we seem to be doing quite well in the TDD space over in the UK :)

Getting NCrunch to work well on a large established solution can sometimes be tricky, as the solution will usually have a development history suited mostly to on-demand synchronous testing. The results you have from NCrunch will always vary depending upon the nature of your solution and the specification of the system you are using. Some solutions just fall right in and work great, and others need to be gradually adjusted over time to get the best result.

With that said, it's an important goal for me to try and make the adjustment process as simple and streamlined as possible. A critical element of this is finding people that have complex and/or demanding solutions to tackle that have the time/commitment to report issues that they're experiencing so I can make the tool smarter - so definitely thanks for getting in touch.

Based on what you've described, I have a feeling that much of the performance drag on your system will be caused by the database. My assumption is that you're running a database server on the same machine as NCrunch, which would mean that the database and Visual Studio are likely to be competing for system resources.

The primary way that NCrunch keeps the load away from the VS UI is by splitting the available work on a different set of CPU cores. It can do this across all the processes it controls (such as Visual studio and the numerous task runner processes), though it isn't able to do this with other external processes that it isn't aware of (such as a local database on the same machine). Something that may be worth trying is to find your main database worker process inside task manager, right clicking it and setting the processor affinity to be the same as the CPU core configuration you've specified in NCrunch.

If your solution is small enough and your available memory is high enough, you could also consider setting up a RAM disk and configuring NCrunch to store its workspaces there. This often makes quite a difference on the HDD load as NCrunch normally builds your projects on disk whenever a change is detected.

A setup that I've found works quite well for large database centric projects is to apply the 'ExclusivelyUses' attribute against all of your database integration tests, giving them the same resource (you could call it 'Database'). This means you can still make use of the parallel execution features for your unit tests (which likely don't drag the system so much), but your database tests will be run synchronously. NCrunch also generally tends to function better on test suites that have a smaller number of slower integration tests and a larger number of fast unit tests.

The test that you are running to interrogate other assemblies can be fixed by referencing the assemblies within the current application domain, rather than trying to load them off disk. NCrunch will automatically pre-load all dependences of an assembly under test into the same application domain before the test starts executing. This means that in an NCrunch test environment, you can rely on them being accessible from AppDomain.CurrentDomain.GetAssemblies() provided your test assembly is referencing them. On a solution of your size, you should do everything you can to avoid the 'Copy Referenced Assemblies To Workspace' setting as it will drag VERY heavily on your build times.

I'm particularly interested in the issues you're experiencing with crashing. Crashes are a very high priority for me and I'd like to learn a bit more about the symptoms you're experiencing. Can give you me any more information?


Thanks!

Remco