www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - unittest-cov - results?

reply Jolly James <j.j jmail.com> writes:
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.
Jul 05 2017
parent reply Seb <seb wilzba.ch> writes:
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
Jul 05 2017
parent reply Jolly James <j.j jmail.com> writes:
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.
Jul 05 2017
parent reply Jolly James <j.j jmail.com> writes:
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.
Jul 05 2017
parent reply Jonathan M Davis via Digitalmars-d-learn writes:
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
Jul 05 2017
next sibling parent reply Jolly James <j.j jmail.com> writes:
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'.
Jul 05 2017
next sibling parent Jonathan M Davis via Digitalmars-d-learn writes:
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
Jul 05 2017
prev sibling parent 0xEAB <desisma heidel.beer> writes:
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.
Jul 25 2017
prev sibling parent Sebastiaan Koppe <mail skoppe.eu> writes:
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.
Jul 05 2017