How to follow execution path of a Unit Test in real time without manually stepping through the code line-by-line?

Question

I'm using MSTest. I have some async functions I'm unit testing that rely upon a lot of different methods where the result needs to be awaited upon. Sometimes the unit tests stall in a "running" stage for a very long time and I'm attempting to pinpoint which blocking operations are taking the longest.

The solutions I can think of around this are - 1) Manually stepping through the code line by line. This is not practically possible since I'm using loops over the same blocking operations which sometimes pass instantly, other times take much longer. The loops can contain many thousands of iterations with different variables so doing a "manual line by line debug" is not feasible.

2) Setting a timeout for each blocking operation which if reached, will go into a conditional block of code with a breakpoint, so that I can immediately see all the program state which led to the blocking operation that timed out.

Option 2 does exactly what I need, however it would require extensive refactoring and in actuality the functionality isn't needed for anything besides this one debug test. I was wondering if there was an in-built solution in either Visual Studio, Jetbrain Rider, or some other IDE or plugin that would allow me to view in real-time the debugger executing each line without me manually needing to click on "Step Over" each line segment? I understand I'd never be able to "catch" the deugger moving in this manner so to speak since it would be moving quickly, unless of course it was being blocked somewhere for a long time, at which time I'd be able to see exactly what is stalling it without needing to custom write timeout logic for every single blocking operation.

Does something like this exist?

Answer 1

Given what you said, what I'd do is probably to send an interrupt (Ctrl+C) when the program hangs. I don't know about C#, bit in many of the languages I've used, this would raise an exception and an uncaught exception would normally end up with printing stack trace, which would give you a hint in where the code was blocking before the interrupt. If the code was stuck in a live infinite loop instead of actually sleeping block, you may need to watch a few retries to get a general idea on which lines of codes you most often spend blocked at, and in that case the method in the next paragraph is likely going to work better.

Another possible way is to start a second thread that'd every few seconds or so print the stack trace of the currently running program. Refer to https://stackoverflow.com/questions/531695/how-to-print-the-current-stack-trace-in-net-without-any-exception on how to print another thread's stack.