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