Hi Ed,
The TestCaseSource factory methods are invoked by NUnit during test discovery, which happens inside the 'Analyse Assembly' tasks in the processing queue. NCrunch runs this after every successful build. The user code inside the factory methods is considered to be a part of the test discovery process. During the test discovery process, the tests themselves haven't been created yet and are unable to carry or represent data. For this reason, any trace data emitted by user code during the analysis task is not captured by NCrunch. However, if an exception is thrown inside a TestCaseSource factory method, this will interrupt the discovery process and bubble up through the task, where it will be displayed in the NCrunch tests window. So there is still at least one way you can get data out of it.
I generally recommend to try and keep TestCaseSource factory methods as simple as you possibly can. Because these methods are run in a context where the data collection is minimal and they cannot be parallelised, they have the potential to be a huge bottleneck and potential stability issue. Problems that appear within these methods can be hard to diagnose with NCrunch and can have far reaching consequences, affecting all tests in the suite.
A better approach would be to rig up each test so that it will clean up for any prior runs of other tests inside a SetUp for TestFixtureSetUp, then create its own data. In this way, no matter what your system is left in, the tests can always run consistently. Making tests clean up after themselves in a TearDown method always seems like an intuitive way to go, but there are situations where TestDown won't be called (for example, if your system loses power or the test process is unexpectedly terminated).
