How to identify the ProcessId (PID) in which a test is running ?

Hi,

Is there an easy way to identify the PID for a given test, while it is executing ?

I wish to attach the performance profiler when I break into a test...

Thanks.

Hi,

At the moment NCrunch doesn't have this feature. There may be a way you can work around this. Try the following:

1. At the start of the test you wish to profile, add the following line of code:

var myPid = System.Diagnostics.Process.GetCurrentProcess().Id;

2. Fire up a debugging session for this test. Break just under the new line of code
3. Check the PID using the debugger
4. Attach the performance profiler to the .EXE with the PID

Other than blind guessing or trying to deductively terminate other test processes, at the moment I'm not sure if there is an easier way to do this.

Ok, actually I use a similar technique with process explorer to identify Ncrunch process when it starts (PE highlights new processes in green).

I expected to find the pid in the Process Queue or Tests window.

Thanks

When support for task termination was added in V2, there were actually plans to add the PID to a column inside the Processing Queue or Tests Window.

Unfortunately, this proved to be somewhat more challenging when working with the grid processing, so the design was changed to use an internal ID instead.

I'd be happy to revisit this with a bit more determination if there is enough interest in it. You're welcome to request it as a feature if you like.

Ok, I created it: https://ncrunch.uservoice.com/forums/245203-feature-requests/suggestions/6387141-show-the-pid-of-process-in-which-a-test-is-running

Is it possible to break into a test with grid processing ? Because the only relevant case in which it's usefull in my opinion is when we break into a test via NCrunch debugging feature. But even in that case, I understand that it can be challenging.

Is it possible to break into a test with grid processing ? Because the only relevant case in which it's usefull in my opinion is when we break into a test via NCrunch debugging feature. But even in that case, I understand that it can be challenging.

Unfortunately not. Breaking into code on a grid node requires remote debugging, which is very challenging to set up and integrate with (if it's actually possible at all).

The problems around providing the process ID for remote processing were down to the details of how the protocol works and the steps involved during the data exchange. A possible solution would be to simply ignore the PID for remotely executing tasks, showing them as (remote) instead.

Remote debugging would be a very cool feature but in my case, I don't use processing grid feature.

So, having a PID if test runners are local is just fine for me.

Thanks for your answers.