How does unit testing with dub work?

> dub build --arch=x86_64 --build=unittest-cov --force --compiler=ldc2

After execution, there is no result output in the command line.

On Wednesday, 5 July 2017 at 17:46:01 UTC, Jolly James wrote:
> How does unit testing with dub work?
>
>> dub build --arch=x86_64 --build=unittest-cov --force --compiler=ldc2
>
> After execution, there is no result output in the command line.

For every file a `<file>.lst` file is generated (it's the same how `-cov` behaves at DMD).
These .lst files contain the original source code with number of hits of a respective line:

      2|    auto copy = new char[s.length + 1];
      2|    copy[0 .. s.length] = s[];
      2|    copy[s.length] = 0;

Maybe you haven't seen the lst files?


Btw if you use Travis, you can use an `after_success` event to your `.travis.yml` to upload the results to CodeCov for a nice visuals & PR integration:

```
after_success:
 - bash <(curl -s https://codecov.io/bash)
```

We do this on most dlang repos, e.g. https://github.com/dlang/phobos/pull/5503

On Wednesday, 5 July 2017 at 18:09:46 UTC, Seb wrote:
> On Wednesday, 5 July 2017 at 17:46:01 UTC, Jolly James wrote:
>> [...]
>
> For every file a `<file>.lst` file is generated (it's the same how `-cov` behaves at DMD).
> These .lst files contain the original source code with number of hits of a respective line:
>
>       2|    auto copy = new char[s.length + 1];
>       2|    copy[0 .. s.length] = s[];
>       2|    copy[s.length] = 0;
>
> Maybe you haven't seen the lst files?
>
>
> Btw if you use Travis, you can use an `after_success` event to your `.travis.yml` to upload the results to CodeCov for a nice visuals & PR integration:
>
> ```
> after_success:
>  - bash <(curl -s https://codecov.io/bash)
> ```
>
> We do this on most dlang repos, e.g. https://github.com/dlang/phobos/pull/5503

where would I find these *.lst files. Searching for '*.lst' in the source's root dir doesn't bring any results.

On Wednesday, 5 July 2017 at 18:46:38 UTC, Jolly James wrote:
> On Wednesday, 5 July 2017 at 18:09:46 UTC, Seb wrote:
>> On Wednesday, 5 July 2017 at 17:46:01 UTC, Jolly James wrote:
>>> [...]
>>
>> For every file a `<file>.lst` file is generated (it's the same how `-cov` behaves at DMD).
>> These .lst files contain the original source code with number of hits of a respective line:
>>
>>       2|    auto copy = new char[s.length + 1];
>>       2|    copy[0 .. s.length] = s[];
>>       2|    copy[s.length] = 0;
>>
>> Maybe you haven't seen the lst files?
>>
>>
>> Btw if you use Travis, you can use an `after_success` event to your `.travis.yml` to upload the results to CodeCov for a nice visuals & PR integration:
>>
>> ```
>> after_success:
>>  - bash <(curl -s https://codecov.io/bash)
>> ```
>>
>> We do this on most dlang repos, e.g. https://github.com/dlang/phobos/pull/5503
>
> where would I find these *.lst files. Searching for '*.lst' in the source's root dir doesn't bring any results.

I have changed the 'build' to 'test' in the command. Now at least I get the following message: "All unit tests have been run successfully." which should not actually happen, as my code contains an 'assert(false);' unittest.

On Wednesday, July 05, 2017 18:50:32 Jolly James via Digitalmars-d-learn wrote:
> On Wednesday, 5 July 2017 at 18:46:38 UTC, Jolly James wrote:
> > On Wednesday, 5 July 2017 at 18:09:46 UTC, Seb wrote:
> >> On Wednesday, 5 July 2017 at 17:46:01 UTC, Jolly James wrote:
> >>> [...]
> >>
> >> For every file a `<file>.lst` file is generated (it's the same
> >> how `-cov` behaves at DMD).
> >> These .lst files contain the original source code with number
> >>
> >> of hits of a respective line:
> >>       2|    auto copy = new char[s.length + 1];
> >>       2|    copy[0 .. s.length] = s[];
> >>       2|    copy[s.length] = 0;
> >>
> >> Maybe you haven't seen the lst files?
> >>
> >>
> >> Btw if you use Travis, you can use an `after_success` event to your `.travis.yml` to upload the results to CodeCov for a nice visuals & PR integration:
> >>
> >> ```
> >>
> >> after_success:
> >>  - bash <(curl -s https://codecov.io/bash)
> >>
> >> ```
> >>
> >> We do this on most dlang repos, e.g. https://github.com/dlang/phobos/pull/5503
> >
> > where would I find these *.lst files. Searching for '*.lst' in the source's root dir doesn't bring any results.
>
> I have changed the 'build' to 'test' in the command. Now at least I get the following message: "All unit tests have been run successfully." which should not actually happen, as my code contains an 'assert(false);' unittest.

If you don't run the tests, you won't get any code coverage. Building with

dub test --coverage

should do it. As for your assert(false) test failing, was it in the same module with your main in it? I ran into a bug in dub not all that long ago where the tests in the module with main in it weren't actually being run even though the other tests were. (which reminds me, I should verify that again and report it).

- Jonathan M Davis

On Wednesday, 5 July 2017 at 19:01:06 UTC, Jonathan M Davis wrote:
> On Wednesday, July 05, 2017 18:50:32 Jolly James via Digitalmars-d-learn wrote:
>> On Wednesday, 5 July 2017 at 18:46:38 UTC, Jolly James wrote:
>> > On Wednesday, 5 July 2017 at 18:09:46 UTC, Seb wrote:
>> >> [...]
>> >
>> > where would I find these *.lst files. Searching for '*.lst' in the source's root dir doesn't bring any results.
>>
>> I have changed the 'build' to 'test' in the command. Now at least I get the following message: "All unit tests have been run successfully." which should not actually happen, as my code contains an 'assert(false);' unittest.
>
> If you don't run the tests, you won't get any code coverage. Building with
>
> dub test --coverage

The following command does not change anything:
  dub test --coverage --arch=x86_64 --compiler=ldc2
All I get is "All unit tests have been run successfully." in the command line.


> should do it. As for your assert(false) test failing, was it in the same module with your main in it?

No, this test is actually in module 'tools.array'.

On Wednesday, July 05, 2017 19:13:21 Jolly James via Digitalmars-d-learn wrote:
> On Wednesday, 5 July 2017 at 19:01:06 UTC, Jonathan M Davis wrote:
> > On Wednesday, July 05, 2017 18:50:32 Jolly James via
> >
> > Digitalmars-d-learn wrote:
> >> On Wednesday, 5 July 2017 at 18:46:38 UTC, Jolly James wrote:
> >> > On Wednesday, 5 July 2017 at 18:09:46 UTC, Seb wrote:
> >> >> [...]
> >> >
> >> > where would I find these *.lst files. Searching for '*.lst' in the source's root dir doesn't bring any results.
> >>
> >> I have changed the 'build' to 'test' in the command. Now at least I get the following message: "All unit tests have been run successfully." which should not actually happen, as my code contains an 'assert(false);' unittest.
> >
> > If you don't run the tests, you won't get any code coverage. Building with
> >
> > dub test --coverage
>
> The following command does not change anything:
>    dub test --coverage --arch=x86_64 --compiler=ldc2
>
> All I get is "All unit tests have been run successfully." in the command line.
>

I don't know why you'd need arch if you're running the tests on the same system that you're building them. And I don't know if ldc has the code coverage stuff that dmd has or not - that depends on which pieces of it are in the front end and which pieces are in the backend. I'd suggest trying it with dmd instead of ldc to see if you get different results. If

dub test --coverage

does work, whereas running it with the extra flags doesn't, then that at least tells you something about what's going wrong.

> > should do it. As for your assert(false) test failing, was it in
> > the same module with your main in it?
>
> No, this test is actually in module 'tools.array'.

I don't know then. It was just a thought based on what I've seen before. Clearly, something is making it so that test doesn't run, but I have no idea what.

dub does have its own forums though, so you probably stand a better chance of getting useful help there:

http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/

- Jonathan M Davis

On Wednesday, 5 July 2017 at 19:01:06 UTC, Jonathan M Davis wrote:
> I ran into a bug in dub not all that long ago where the tests in the module with main in it weren't actually being run even though the other tests were. (which reminds me, I should verify that again and report it).
>
> - Jonathan M Davis

Noticed it as well couple of months ago. I think dub just skips the mainSourceFile defined in the dub.sdl (default: source/app.d) to avoid having 2 mains.

It is annoying especially for small projects where you would only have app.d. Especially if you don't have a clue what is going on.

On Wednesday, 5 July 2017 at 19:13:21 UTC, Jolly James wrote:
> On Wednesday, 5 July 2017 at 19:01:06 UTC, Jonathan M Davis wrote:
>> On Wednesday, July 05, 2017 18:50:32 Jolly James via Digitalmars-d-learn wrote:
>>> On Wednesday, 5 July 2017 at 18:46:38 UTC, Jolly James wrote:
>>> > [...]
>>>
>>> I have changed the 'build' to 'test' in the command. Now at least I get the following message: "All unit tests have been run successfully." which should not actually happen, as my code contains an 'assert(false);' unittest.
>>
>> If you don't run the tests, you won't get any code coverage. Building with
>>
>> dub test --coverage
>
> The following command does not change anything:
>   dub test --coverage --arch=x86_64 --compiler=ldc2
> All I get is "All unit tests have been run successfully." in the command line.
>
>
>> should do it. As for your assert(false) test failing, was it in the same module with your main in it?
>
> No, this test is actually in module 'tools.array'.

Hello,

I faced a similar issue today. In my case the utests weren't run because they were part of a templated class. They don't get executed in such a case because a valid utest mustn't be templated.