• Shammah Chancellor (12/12) Oct 27 2014 So, I'm trying to setup code coverage to ensure that we are testing
• Daniel Murphy (5/18) Oct 27 2014 Yes, I have. The answers are all in the coverage implementation in

Shammah Chancellor <email domain.com> writes:

So,  I'm trying to setup code coverage to ensure that we are testing 
100% of the SDC LOC when we run our tests.

Issues I'm having:

1) Combined lst files from multiple results.

2) Seems to be some conditions on when lst files are generated.  If the 
binary is invoked from somewhere other than where it was compiled, or 
the source and obj files are not around it doesn't generate anything.

3) Given 2 above,  how do you get cov on libraries included in another binary?

I'm sure there are other issues, but those are the ones I've run into so far.

Any ideas?

As an aside, has anyone tried to do this with ddmd?

-S.

"Daniel Murphy" <yebbliesnospam gmail.com> writes:

"Shammah Chancellor"  wrote in message news:m2leau$2km8$1 digitalmars.com...

 So,  I'm trying to setup code coverage to ensure that we are testing 100% 
 of the SDC LOC when we run our tests.

 Issues I'm having:

 1) Combined lst files from multiple results.

 2) Seems to be some conditions on when lst files are generated.  If the 
 binary is invoked from somewhere other than where it was compiled, or the 
 source and obj files are not around it doesn't generate anything.

 3) Given 2 above,  how do you get cov on libraries included in another 
 binary?

 I'm sure there are other issues, but those are the ones I've run into so 
 far.

 Any ideas?

 As an aside, has anyone tried to do this with ddmd?

Yes, I have.  The answers are all in the coverage implementation in 
druntime.  You can override the paths to make it work when called from 
somewhere other than where it was compiled.  IIRC there is also a way to 
make it combine lst files instead of overwriting.