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?

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?
>

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.

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.
>

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.