www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Coverage

reply Sebastiaan Koppe <mail skoppe.eu> writes:
I currently run dmd's coverage on my unittests.

But now I also want to execute my program with different inputs 
and then merge all that coverage info from each run.

Any chance there is something for that?
Feb 16 2016
parent reply Leandro Motta Barros via Digitalmars-d-learn writes:
You probably already though of it, but: can't you create a unittest that
calls your code as many times as desired, passing different input each time?

LMB


On Tue, Feb 16, 2016 at 10:16 AM, Sebastiaan Koppe via Digitalmars-d-learn <
digitalmars-d-learn puremagic.com> wrote:


 I currently run dmd's coverage on my unittests.

 But now I also want to execute my program with different inputs and then
 merge all that coverage info from each run.

 Any chance there is something for that?
Feb 16 2016
next sibling parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Tuesday, 16 February 2016 at 12:35:38 UTC, Leandro Motta 
Barros wrote:

 You probably already though of it, but: can't you create a 
 unittest that calls your code as many times as desired, passing 
 different input each time?


That is a viable option yes. I will probably end up doing it like 
that.

I don't like it though. Since the input is pretty big, it would 
need to be kept in an external file. And I don't like my 
unittests reading files. Plus they aren't really unittests 
either. Oh well. Moving on.
Feb 16 2016
parent Leandro Motta Barros via Digitalmars-d-learn writes:
I had one case these days in which I also had a lot of data to use in the
test. I was able to put the data as very large regular D arrays, but this
increased my compilation times a lot (not to mention the time to run the
unit tests).

I decided to enclose this specific unit test (including the `import
test_data` statement) in `version ExtraUnitTests { ... }`. This way, I can
run the bulk of my unit tests very frequently without wasting time with
this special case I want to run only sometimes.

I can't say I am 100% happy with this, but it worked for me and didn't
require any additional dependency.

LMB





On Tue, Feb 16, 2016 at 4:58 PM, Sebastiaan Koppe via Digitalmars-d-learn <
digitalmars-d-learn puremagic.com> wrote:


 On Tuesday, 16 February 2016 at 12:35:38 UTC, Leandro Motta Barros wrote:


 You probably already though of it, but: can't you create a unittest that
 calls your code as many times as desired, passing different input each time?


 That is a viable option yes. I will probably end up doing it like that.

 I don't like it though. Since the input is pretty big, it would need to be
 kept in an external file. And I don't like my unittests reading files. Plus
 they aren't really unittests either. Oh well. Moving on.
Feb 16 2016
prev sibling parent Chris Wright <dhasenan gmail.com> writes:
On Tue, 16 Feb 2016 10:35:38 -0200, Leandro Motta Barros via
Digitalmars-d-learn wrote:


 You probably already though of it, but: can't you create a unittest that
 calls your code as many times as desired, passing different input each
 time?


dmd -cov doesn't look specifically at unittests, so another option would 
be to create, effectively, an alternate main() function just for this 
purpose:

int realMain(string[] args) { ... }
int main(string[] args) {
  version(AppCoverage) {
    realMain(["arg1", "arg2"]);
    realMain(["arg3", "arg4"]);
    return 0;
  } else {
    return realMain(args);
  }
}

This only deals with one build configuration, though, which is why it's 
better to be able to combine coverage reports.
Feb 16 2016