Multi threaded code coverage

Will NCover capture coverage of code running in multiple threads? Is there any specific setting for this? Our dll is multithreaded and we are seeing zero coverage even though our unit tests are hitting the code. It happens to be in a separate thread from the thread which started the NUnit test.

Any suggestions? We are evaluating buying a 2.0 license and this is critical.

Thanks -Sundar

RE: Multi threaded code coverage

NCover will generate coverage data on all threads running in the process that NCover is monitoring.

If NCover can't find PDBs for the executing dlls, then it won't generate coverage data. If the dlls run in a separate process, then NCover won't generate coverage data (w/o configuration). If the dlls run as a service (web or otherwise), then NCover won't generate coverage (w/o configuration).

If you could explain your test setup in more detail, including the type of process you're profiling, I would be happy to help you configure NCover. If this forum is too public, you can email me here: support at gnoso dot com just mention this forum post in the email.

Stephen

RE: Multi threaded code coverage

I also having the same issue. Our application has multiple threads and test cases run in separate (child) threads. Seems NCover doesn't cover the codes run in child threads.

Below is the code we use to create child threads.

public static void RunThreadedApart(ThreadStart userDelegate) { Exception lastException = null; Thread t = new Thread( delegate() { try { userDelegate.Invoke(); ///******Test cases will run here. userDelegate contains test cases. } catch (Exception e) { lastException = e; } }); t.SetApartmentState(ApartmentState.STA); t.Start(); t.Join(); if (lastException != null) { //...... } }

Here is the command I run on Cmd

NCover.Console "C:\Program Files (x86)\NUnit 2.4.7\bin\NUnit-Console" StandardOperators-tests.dll //a "SOperators-tests;SOperators" //html .\HtmlReport\

Is there any way to cover the code executing in separate threads?

Thanks!

RE: Multi threaded code coverage

I have answered this question by replying to the email you sent to support

RE: Multi threaded code coverage

I have the same problem too. So I wonder what the answer would be. It would be kind, if you can post it to the forum.

Thanks, Carsten

RE: Multi threaded code coverage

If I recall, the short answer was that the delegate call started a separate process, which NCover did not cover because NCover wa already covering the process that started the other process. Is your situation similiar, or does all of the missing executed code execute in the same process that executes the delegate?

RE: Multi threaded code coverage

No, it's all in the same process. The process is an application server that starts separate threads. But that should not be a problem?

But our unit test starts two NCover-Consoles on the same machine. One for the client, that uses nunit-console and one for the application server executable. Could that be a problem? The application server is started as an executable, not as service.

Thanks, Carsten

RE: Multi threaded code coverage

I will check on monday to see if this is an issue. I know we use shared memory so this may be an issue.

RE: Multi threaded code coverage

running multiple instances of NCover at the same time should work, as the shared memory is local to each process. Can you provide more detail on what you're doing/trying to do?

RE: Multi threaded code coverage

After further research my problem has nothing to do with two NCover processes. It seems that NCover has problems with our application server - because the application server does not report successful startup in some cases. But it also does not report any error messages. But the client nunit-tests fail because they can't connect to the application server. Without ncovering our application server the client tests are successful.

RE: Multi threaded code coverage

I have elevated this thread to a support request, since that format lets us better track progress on the issue and leads to a quicker resolution.

Stephen Ward