When testing with Visual Studio Team Test unhandled exceptions in tests are caught and reported in the results. So I was kind of surprised to see the test hosting process (V
Having more than one thread in your tests doesn't sound very unity to me. Is there anything about the logic that is under test that dictates that there must be several threads? Really?
Or is it the case that there are some collaborators of the code under test that happens to be multithreaded (like the socket)? If that is the case, you really should substitute those collaborators with some kind of test doubles (mocks, stubs or whatever). The added benefit of using test doubles is that you can control their behaviour and responses easier than you could if they were the real thing.
You can use a Global Exception handler to catch all of the uncaught exception in the AppDomain:
AppDomain currentDomain = AppDomain.CurrentDomain;
currentDomain.UnhandledException += new EventHandler(UnhandledExceptionHandler);
I think it would work for exceptions thrown from other threads as well
Generally I try to avoid starting threads in unit tests by injecting a thread provider that, during unit tests, doesn't actually provide a thread, but rather executes syncronously.
Of course, with that approach you can't test any kind of potential contention, or two real code paths running in parallel, but there is a good argument to be made that such a test isn't really a unit test.
When you do test two simultaneous threads, then you need a thread provider which catches exceptions at the end of the the thread and reports them as failures.
You could try setting AppDomain.CurrentDomain.UnhandledException
and see if that works? I don't know how that interacts with the VS test harness thought
What I can say from the realm of C++ (if the knowledge can be translated) is that any exception thrown in a given thread can only be caught in that thread. If your main application launches three other threads, then you have to catch exceptions from each of the (now 4) threads independently. There is no way to implement a "global" exception handler in threaded code. This has to do with how threads (and processes) are implemented in the OS.
But like I said, I don't know how closely that logic translates to C#, because it runs on top of a VM like Java.
A couple of ideas: