www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Code coverage in Phobos

reply Seb <seb wilzba.ch> writes:
AFAIK dmd supports the `-cov` flag since quite some time, so I 
would be interested why there's no code coverage bot. There also 
seems to exist at least two external platforms that allow such 
code coverage analyzing [1, 2]. Is this already on your roadmap?

[1] https://github.com/codecov/example-d
[2] https://github.com/ColdenCullen/doveralls/issues/16

Anyways it seems pretty easy to hack something quick&dirty 
together that could be pretty helpful:

```
for f in $(find . -name '*.d' -type f -not -path './c/*'); do 
;fe="${f%.*}"; (cd $(dirname "$f") && rdmd -cov -unittest -main 
"$(basename $f)") && printf "$f " && tail -n1 "$fe".lst | cut -f3 
-d ' ' ; done | sort
```

./algorithm/comparison.d 95%
./algorithm/internal.d no
./algorithm/iteration.d 96%
./algorithm/mutation.d 99%
./algorithm/package.d no
./algorithm/searching.d 97%
./algorithm/setops.d 94%
./algorithm/sorting.d 98%
./array.d 95%
./ascii.d 100%
./base64.d 94%
./bigint.d 97%
./bitmanip.d 96%
./compiler.d no
./complex.d 96%
./concurrencybase.d 100%
./container/array.d 94%
./container/binaryheap.d 59%
./container/dlist.d 92%
./container/package.d 1%
./container/rbtree.d 94%
./container/slist.d 95%
./container/util.d 100%
./conv.d 94%
./cstream.d 92%
./datetime.d 94%
./demangle.d 0%
./digest/crc.d 100%
./digest/digest.d 72%
./digest/hmac.d 100%
./digest/md.d 100%
./digest/ripemd.d 100%
./digest/sha.d 80%
./encoding.d 66%
./exception.d 92%
./experimental/allocator/building_blocks/affix_allocator.d 71%
./experimental/allocator/building_blocks/allocator_list.d 81%
./experimental/allocator/building_blocks/bitmapped_block.d 91%
./experimental/allocator/building_blocks/bucketizer.d 48%
./experimental/allocator/building_blocks/fallback_allocator.d 89%
./experimental/allocator/building_blocks/free_list.d 75%
./experimental/allocator/building_blocks/kernighan_ritchie.d 80%
./experimental/allocator/building_blocks/null_allocator.d 56%
./experimental/allocator/building_blocks/package.d no
./experimental/allocator/building_blocks/quantizer.d 69%
./experimental/allocator/building_blocks/region.d 70%
./experimental/allocator/building_blocks/scoped_allocator.d 78%
./experimental/allocator/building_blocks/segregator.d 50%
./experimental/allocator/building_blocks/stats_collector.d 95%
./experimental/allocator/common.d 88%
./experimental/allocator/gc_allocator.d 92%
./experimental/allocator/mmap_allocator.d 100%
./experimental/allocator/showcase.d 100%
./experimental/allocator/typed.d 54%
./experimental/logger/core.d 99%
./experimental/logger/filelogger.d 91%
./experimental/logger/multilogger.d 100%
./experimental/logger/nulllogger.d 100%
./experimental/logger/package.d no
./experimental/ndslice/internal.d 100%
./experimental/ndslice/iteration.d 100%
./experimental/ndslice/package.d 91%
./experimental/ndslice/selection.d 97%
./experimental/ndslice/slice.d 95%
./file.d 93%
./format.d 92%
./functional.d 88%
./internal/cstring.d 93%
./internal/digest/sha_SSSE3.d 0%
./internal/math/biguintcore.d 58%
./internal/math/biguintnoasm.d 75%
./internal/math/biguintx86.d no
./internal/math/errorfunction.d 92%
./internal/math/gammafunction.d 94%
./internal/processinit.d no
./internal/scopebuffer.d 98%
./internal/test/dummyrange.d 100%
./internal/test/uda.d no
./internal/unicode_comp.d 0%
./internal/unicode_decomp.d 0%
./internal/unicode_grapheme.d no
./internal/unicode_norm.d no
./internal/unicode_tables.d 0%
./internal/windows/advapi32.d no
./json.d 93%
./math.d 92%
./mathspecial.d 47%
./meta.d 97%
./mmfile.d 61%
./net/curl.d 68%
./net/isemail.d 84%
./numeric.d 72%
./outbuffer.d 54%
./parallelism.d 88%
./path.d 97%
./random.d 94%
./range/interfaces.d 78%
./range/package.d 92%
./range/primitives.d 90%
./regex/internal/backtracking.d 0%
./regex/internal/generator.d 56%
./regex/internal/kickstart.d 87%
./regex/internal/parser.d 29%
./regex/internal/tests.d 99%
./regex/internal/thompson.d no
./regex/package.d 90%
./signals.d 92%
./socketstream.d 0%
./stdint.d no
./stdio.d 76%
./stdiobase.d 100%
./stream.d 61%
./string.d 99%
./system.d no
./typecons.d 90%
./typetuple.d 80%
./uni.d 91%
./utf.d 90%
./uuid.d 97%
./variant.d 92%
./windows/charset.d no
./windows/iunknown.d no
./windows/registry.d no
./windows/syserror.d no
./xml.d 64%
./zip.d 90%
./zlib.d 60%
Mar 27 2016
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Monday, 28 March 2016 at 01:30:34 UTC, Seb wrote:

 AFAIK dmd supports the `-cov` flag since quite some time, so I 
 would be interested why there's no code coverage bot. There 
 also seems to exist at least two external platforms that allow 
 such code coverage analyzing [1, 2]. Is this already on your 
 roadmap?

 [1] https://github.com/codecov/example-d
 [2] https://github.com/ColdenCullen/doveralls/issues/16

 Anyways it seems pretty easy to hack something quick&dirty 
 together that could be pretty helpful:


Yep. The difficulties are:

1. Getting data off the autotester. Currently it's nearly 
impossible, as is making any changes to it.

https://issues.dlang.org/show_bug.cgi?id=14381

2. Collating data from multiple platforms, as there is a lot of 
platform-specific code in e.g. std.stdio, std.file, and most of 
Druntime.
Mar 28 2016
next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Monday, 28 March 2016 at 11:29:55 UTC, Vladimir Panteleev 
wrote:

 Yep. The difficulties are:

 1. Getting data off the autotester. Currently it's nearly 
 impossible, as is making any changes to it.

 https://issues.dlang.org/show_bug.cgi?id=14381

 2. Collating data from multiple platforms, as there is a lot of 
 platform-specific code in e.g. std.stdio, std.file, and most of 
 Druntime.


3. since the coverage is computed at run-time by the application 
that runs the tests all the static code (+ CTFE) is considered 
NOT covered. This gives misleading results.

For example std.traits will probably have a bad coverage while 
actually it's pretty good.
Mar 28 2016
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Monday, 28 March 2016 at 16:10:48 UTC, Basile B. wrote:

 On Monday, 28 March 2016 at 11:29:55 UTC, Vladimir Panteleev 
 wrote:

 Yep. The difficulties are:

 1. Getting data off the autotester. Currently it's nearly 
 impossible, as is making any changes to it.

 https://issues.dlang.org/show_bug.cgi?id=14381

 2. Collating data from multiple platforms, as there is a lot 
 of platform-specific code in e.g. std.stdio, std.file, and 
 most of Druntime.


 3. since the coverage is computed at run-time by the 
 application that runs the tests all the static code (+ CTFE) is 
 considered NOT covered. This gives misleading results.

 For example std.traits will probably have a bad coverage while 
 actually it's pretty good.


Not really an issue since DMD only counts the code that goes into 
the binary for coverage. Uncovered lines will have seven zeroes 
before the |, whereas lines with no compiled code will have 
nothing.
Mar 28 2016
parent reply Basile B. <b2.temp gmx.com> writes:
On Monday, 28 March 2016 at 16:44:26 UTC, Vladimir Panteleev 
wrote:

 On Monday, 28 March 2016 at 16:10:48 UTC, Basile B. wrote:

 On Monday, 28 March 2016 at 11:29:55 UTC, Vladimir Panteleev 
 wrote:

 Yep. The difficulties are:

 1. Getting data off the autotester. Currently it's nearly 
 impossible, as is making any changes to it.

 https://issues.dlang.org/show_bug.cgi?id=14381

 2. Collating data from multiple platforms, as there is a lot 
 of platform-specific code in e.g. std.stdio, std.file, and 
 most of Druntime.


 3. since the coverage is computed at run-time by the 
 application that runs the tests all the static code (+ CTFE) 
 is considered NOT covered. This gives misleading results.

 For example std.traits will probably have a bad coverage while 
 actually it's pretty good.


 Not really an issue since DMD only counts the code that goes 
 into the binary for coverage. Uncovered lines will have seven 
 zeroes before the |, whereas lines with no compiled code will 
 have nothing.


Not true. I wouldn't be able to link an example in Phobos but 
this is a more general issue with coverage. For example take a 
file with:


template isSomething(T)
{
     bool helper()
     {
         return true; // line 5
     }
     enum isSomething = helper;
}

unittest
{
     bool test;
     static if (isSomething!bool)
     {test = true;}
     assert(test);
}

and compile with -main -unittest -cov then run.
the lst file indicates 00000 for line 5.

Actually with `static if()` and helpers functions executed at 
compile time, 100% coverage is unreachchable. This is more or 
less the same that happens with if(__ctfe) branches.
Mar 28 2016
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Monday, 28 March 2016 at 23:45:10 UTC, Basile B. wrote:

 On Monday, 28 March 2016 at 16:44:26 UTC, Vladimir Panteleev 
 wrote:

 On Monday, 28 March 2016 at 16:10:48 UTC, Basile B. wrote:

 On Monday, 28 March 2016 at 11:29:55 UTC, Vladimir Panteleev 
 wrote:

 Yep. The difficulties are:

 1. Getting data off the autotester. Currently it's nearly 
 impossible, as is making any changes to it.

 https://issues.dlang.org/show_bug.cgi?id=14381

 2. Collating data from multiple platforms, as there is a lot 
 of platform-specific code in e.g. std.stdio, std.file, and 
 most of Druntime.


 3. since the coverage is computed at run-time by the 
 application that runs the tests all the static code (+ CTFE) 
 is considered NOT covered. This gives misleading results.

 For example std.traits will probably have a bad coverage 
 while actually it's pretty good.


 Not really an issue since DMD only counts the code that goes 
 into the binary for coverage. Uncovered lines will have seven 
 zeroes before the |, whereas lines with no compiled code will 
 have nothing.


 Not true. I wouldn't be able to link an example in Phobos but 
 this is a more general issue with coverage. For example take a 
 file with:


Ah, OK. Though, this is something that could be improved in the 
implementation without changing the language. DMD should not emit 
code that's not called in the module, and not callable from 
outside the module due to e.g. being private. Probably would help 
with template bloat, too. LTO would probably take care of that in 
theory, I wonder if LDC's or GDC's LTO doesn't have this issue 
(not that it would help testing Phobos coverage).
Mar 28 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2016 9:38 PM, Vladimir Panteleev wrote:

 Ah, OK. Though, this is something that could be improved in the implementation
 without changing the language. DMD should not emit code that's not called in
the
 module, and not callable from outside the module due to e.g. being private.
 Probably would help with template bloat, too. LTO would probably take care of
 that in theory, I wonder if LDC's or GDC's LTO doesn't have this issue (not
that
 it would help testing Phobos coverage).



Or one could write unit tests specifically for the helper functions. (I've done 
that.)
Mar 29 2016
parent reply Basile B. <b2.temp gmx.com> writes:
On Tuesday, 29 March 2016 at 09:39:49 UTC, Walter Bright wrote:

 On 3/28/2016 9:38 PM, Vladimir Panteleev wrote:

 Ah, OK. Though, this is something that could be improved in 
 the implementation
 without changing the language. DMD should not emit code that's 
 not called in the
 module, and not callable from outside the module due to e.g. 
 being private.
 Probably would help with template bloat, too. LTO would 
 probably take care of
 that in theory, I wonder if LDC's or GDC's LTO doesn't have 
 this issue (not that
 it would help testing Phobos coverage).



 Or one could write unit tests specifically for the helper 
 functions. (I've done that.)


I've also done so in my user lib. Actually I've particpated to 
this topic because of this:

https://issues.dlang.org/show_bug.cgi?id=15590

3 monthes ago I had never used D coverage feature. Initially I 
thought that the coverage file was generated by static analysis 
(until someone points me 
https://dlang.org/phobos/core_runtime.html#.dmd_coverDestPath)...

Couldn't the coverage be done at compile time ? (even if I 
directly see corner cases like functions only called by delegate)
Mar 29 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/29/2016 3:33 AM, Basile B. wrote:

 Couldn't the coverage be done at compile time ?


The implementation for that would be utterly different.
Mar 29 2016
prev sibling parent reply Seb <seb wilzba.ch> writes:
On Monday, 28 March 2016 at 11:29:55 UTC, Vladimir Panteleev 
wrote:

 On Monday, 28 March 2016 at 01:30:34 UTC, Seb wrote:

 AFAIK dmd supports the `-cov` flag since quite some time, so I 
 would be interested why there's no code coverage bot. There 
 also seems to exist at least two external platforms that allow 
 such code coverage analyzing [1, 2]. Is this already on your 
 roadmap?

 [1] https://github.com/codecov/example-d
 [2] https://github.com/ColdenCullen/doveralls/issues/16

 Anyways it seems pretty easy to hack something quick&dirty 
 together that could be pretty helpful:


 Yep. The difficulties are:

 1. Getting data off the autotester. Currently it's nearly 
 impossible, as is making any changes to it.

 https://issues.dlang.org/show_bug.cgi?id=14381

 2. Collating data from multiple platforms, as there is a lot of 
 platform-specific code in e.g. std.stdio, std.file, and most of 
 Druntime.


Okay I see that for the long run we need a better way to handle 
the testing infrastructure :/

Can't we focus for the near future on getting a simple Phobos 
coverage tester that just compares the coverage of all files 
changes like your DAutoTest?
With this approach we can still prevent regression and show 
improvements.
Mar 29 2016
parent reply Seb <seb wilzba.ch> writes:
On Tuesday, 29 March 2016 at 20:50:57 UTC, Seb wrote:

 Okay I see that for the long run we need a better way to handle 
 the testing infrastructure :/


Actually the idea of achieving "100% coverage" is that we test 
every line at least once and don't let this testing by done by 
users.
So to refresh the discussion - there were two general ideas

1) Find "bad", "dangerous" modules, e.g.

/xml.d 64%
/zlib.d 60%
/experimental/allocator/typed.d 54%
/experimental/allocator/building_blocks/segregator.d 50%
/experimental/allocator/building_blocks/bucketizer.d 48%
/encoding.d 66%
/container/binaryheap.d 59%
/digest/digest.d 72%

2) Increase coverage for generic, platform-independent modules 
like std.algorithm to 100%

I know it's a lot of work, but shouldn't that make our jobs us 
maintainers easier (=catch the bugs before you have to fix 
them?). Therefore I am bumping this ;-)
May 24 2016
parent reply Seb <seb wilzba.ch> writes:
On Wednesday, 25 May 2016 at 02:34:44 UTC, Seb wrote:

 On Tuesday, 29 March 2016 at 20:50:57 UTC, Seb wrote:

 Okay I see that for the long run we need a better way to 
 handle the testing infrastructure :/


 Actually the idea of achieving "100% coverage" is that we test 
 every line at least once and don't let this testing by done by 
 users.
 So to refresh the discussion - there were two general ideas

 1) Find "bad", "dangerous" modules, e.g.

 /xml.d 64%
 /zlib.d 60%
 /experimental/allocator/typed.d 54%
 /experimental/allocator/building_blocks/segregator.d 50%
 /experimental/allocator/building_blocks/bucketizer.d 48%
 /encoding.d 66%
 /container/binaryheap.d 59%
 /digest/digest.d 72%

 2) Increase coverage for generic, platform-independent modules 
 like std.algorithm to 100%

 I know it's a lot of work, but shouldn't that make our jobs us 
 maintainers easier (=catch the bugs before you have to fix 
 them?). Therefore I am bumping this ;-)


Just a quick follow-up on this. I finally managed to work a bit 
on the export to Codecov.io - it's pretty neat as it will warn 
reviewers if the coverage decreases due to changes in a PR.
Moreover according to Codecov.io, Phobos currently has an overall 
coverage of 88.15% (the actual coverage is a bit higher, because 
I had to disable a few tests for Travis and missing, "uncovered" 
lines are also reported for e.g. deprecated lines).

So if someone wants to improve not well-tested modules, at [1] is 
a list of all modules in Phobos with their coverage. Some 
highlights include:

regex: 51%
encoding.d: 62%
mathspecial: 57%
mmfile: 61%
process: 69%
socket: 66%
zlib: 60%

Hopefully in a few days this will be part of Phobos (see [2] for 
details) and thus automatically updated ;-)

[1] 
https://codecov.io/gh/wilzbach/phobos/tree/5fc9eb90076101c0266fb3491ac68527d3520fba/std
[2] https://github.com/dlang/phobos/pull/4587
Jul 09 2016
parent reply Seb <seb wilzba.ch> writes:
On Sunday, 10 July 2016 at 02:38:07 UTC, Seb wrote:

 On Wednesday, 25 May 2016 at 02:34:44 UTC, Seb wrote:

 On Tuesday, 29 March 2016 at 20:50:57 UTC, Seb wrote:

 Okay I see that for the long run we need a better way to 
 handle the testing infrastructure :/


 Actually the idea of achieving "100% coverage" is that we test 
 every line at least once and don't let this testing by done by 
 users.
 So to refresh the discussion - there were two general ideas

 1) Find "bad", "dangerous" modules, e.g.

 /xml.d 64%
 /zlib.d 60%
 /experimental/allocator/typed.d 54%
 /experimental/allocator/building_blocks/segregator.d 50%
 /experimental/allocator/building_blocks/bucketizer.d 48%
 /encoding.d 66%
 /container/binaryheap.d 59%
 /digest/digest.d 72%

 2) Increase coverage for generic, platform-independent modules 
 like std.algorithm to 100%

 I know it's a lot of work, but shouldn't that make our jobs us 
 maintainers easier (=catch the bugs before you have to fix 
 them?). Therefore I am bumping this ;-)


 Just a quick follow-up on this. I finally managed to work a bit 
 on the export to Codecov.io - it's pretty neat as it will warn 
 reviewers if the coverage decreases due to changes in a PR.
 Moreover according to Codecov.io, Phobos currently has an 
 overall coverage of 88.15% (the actual coverage is a bit 
 higher, because I had to disable a few tests for Travis and 
 missing, "uncovered" lines are also reported for e.g. 
 deprecated lines).

 So if someone wants to improve not well-tested modules, at [1] 
 is a list of all modules in Phobos with their coverage. Some 
 highlights include:

 regex: 51%
 encoding.d: 62%
 mathspecial: 57%
 mmfile: 61%
 process: 69%
 socket: 66%
 zlib: 60%

 Hopefully in a few days this will be part of Phobos (see [2] 
 for details) and thus automatically updated ;-)

 [1] 
 https://codecov.io/gh/wilzbach/phobos/tree/5fc9eb90076101c0266fb3491ac68527d3520fba/std
 [2] https://github.com/dlang/phobos/pull/4587


Short update - the experiment is now live. Please help to kill 
the uncovered bits in Phobos :)
A short overview of features CodeCov provides:

1) A CodeCov bot will warn the reviewers if (a) the code coverage 
decreased or (b) there are new, unhit lines added within a PR.

2) For every commit one can browse the current code coverage of 
all modules
https://codecov.io/gh/dlang/phobos/tree/77bee525787a90759211dfeb7103ca608bb44bf0/std

3) They provide a handy dashboard with an overview of historic 
information

https://codecov.io/gh/dlang/phobos

(It's a bit empty atm, it might look like this: 
https://codecov.io/gh/libmir/mir)

4) CodeCov has a bunch of other features, for example browser 
extensions that integrate the code coverage report directly onto 
Github diffs:

https://github.com/codecov/browser-extension

That being said the current approach isn't perfect (see the PR 
for details), but it's hopefully a start to pay more attention to 
code coverage ;-)
Jul 28 2016
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/28/2016 7:16 AM, Seb wrote:

 4) CodeCov has a bunch of other features, for example browser extensions that
 integrate the code coverage report directly onto Github diffs:

 https://github.com/codecov/browser-extension


I installed the browser extension for Chrome, but it says "no coverage" for 
every Phobos PR I tried it on. Also, the umbrella icon is greyed out. 
Something's amiss?
Jul 28 2016
parent reply Seb <seb wilzba.ch> writes:
On Thursday, 28 July 2016 at 17:56:49 UTC, Walter Bright wrote:

 On 7/28/2016 7:16 AM, Seb wrote:

 4) CodeCov has a bunch of other features, for example browser 
 extensions that
 integrate the code coverage report directly onto Github diffs:

 https://github.com/codecov/browser-extension


 I installed the browser extension for Chrome, but it says "no 
 coverage" for every Phobos PR I tried it on. Also, the umbrella 
 icon is greyed out. Something's amiss?


Hmm I guess we bumped into this issue: 
https://github.com/codecov/browser-extension/issues/22 - last 
time their support team was pretty fast, so I hope we can resolve 
this issue soon :)

Do you see the Code coverage overlay for this diff?

https://github.com/dlang/phobos/commit/6db08d3dadb007d930a4042a6140ca4fb22ea540

and on this file?

https://github.com/dlang/phobos/blob/master/std/algorithm/iteration.d

Older PRs don't show a coverage report, because the report needs 
to be uploaded & they don't have this in their `.travis.yml` yet. 
However rebasing should fix this.
Jul 28 2016
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/28/2016 11:51 AM, Seb wrote:

 Do you see the Code coverage overlay for this diff?

 https://github.com/dlang/phobos/commit/6db08d3dadb007d930a4042a6140ca4fb22ea540


Yes. Took me a moment to realize the green box meant covered.


 and on this file?

 https://github.com/dlang/phobos/blob/master/std/algorithm/iteration.d


Yes.


 Older PRs don't show a coverage report, because the report needs to be uploaded
 & they don't have this in their `.travis.yml` yet. However rebasing should fix
 this.


Thanks! Looks like I'll rebase all of my PRs and we'll see how it works!
Jul 28 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/28/2016 11:51 AM, Seb wrote:

 Older PRs don't show a coverage report, because the report needs to be uploaded
 & they don't have this in their `.travis.yml` yet. However rebasing should fix
 this.


I rebased https://github.com/dlang/phobos/pull/4657 but it still shows [No
coverage]
Jul 28 2016
parent reply Seb <seb wilzba.ch> writes:
On Thursday, 28 July 2016 at 20:30:50 UTC, Walter Bright wrote:

 On 7/28/2016 11:51 AM, Seb wrote:

 Older PRs don't show a coverage report, because the report 
 needs to be uploaded
 & they don't have this in their `.travis.yml` yet. However 
 rebasing should fix
 this.


 I rebased https://github.com/dlang/phobos/pull/4657 but it 
 still shows [No coverage]


... but it shows that those three lines are never hit ;-)

As far as I understood [1] the problem is that the CodeCov 
browser extension has troubles handling merge commits. I will 
ping you once they resolved the issue and the PR view is working.

For now you can click on "Last update 6db08d3...bb94012" to see 
the diff with overlayed code coverage.

[1] https://github.com/codecov/browser-extension/issues/22
Jul 28 2016
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/28/2016 1:46 PM, Seb wrote:

 For now you can click on "Last update 6db08d3...bb94012" to see the diff with
 overlayed code coverage.


I don't see where that link is.
Jul 28 2016
parent reply Seb <seb wilzba.ch> writes:
On Thursday, 28 July 2016 at 23:11:04 UTC, Walter Bright wrote:

 On 7/28/2016 1:46 PM, Seb wrote:

 For now you can click on "Last update 6db08d3...bb94012" to 
 see the diff with
 overlayed code coverage.


 I don't see where that link is.


Sorry about being so vague.

e.g. on this PR (https://github.com/dlang/phobos/pull/4657), 
there is the following message. The link "Last update" is on the 
last line.

Current coverage is 88.68% (diff: 87.09%)



==========================================
   Files           121        121
   Lines         73827      73849    +22
   Methods           0          0
   Messages          0          0
   Branches          0          0
==========================================
+ Hits          65471      65492    +21
- Misses         8356       8357     +1
   Partials          0          0
Powered by Codecov. Last update 6db08d3...2002c65 <-- CLICK HERE
Jul 28 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/28/2016 4:39 PM, Seb wrote:

 e.g. on this PR (https://github.com/dlang/phobos/pull/4657), there is the
 following message. The link "Last update" is on the last line.


Ok, I see it now. Thanks!
Jul 28 2016
prev sibling parent reply Seb <seb wilzba.ch> writes:
On Thursday, 28 July 2016 at 20:46:13 UTC, Seb wrote:

 On Thursday, 28 July 2016 at 20:30:50 UTC, Walter Bright wrote:

 On 7/28/2016 11:51 AM, Seb wrote:

 Older PRs don't show a coverage report, because the report 
 needs to be uploaded
 & they don't have this in their `.travis.yml` yet. However 
 rebasing should fix
 this.


 I rebased https://github.com/dlang/phobos/pull/4657 but it 
 still shows [No coverage]


 ... but it shows that those three lines are never hit ;-)

 As far as I understood [1] the problem is that the CodeCov 
 browser extension has troubles handling merge commits. I will 
 ping you once they resolved the issue and the PR view is 
 working.

 For now you can click on "Last update 6db08d3...bb94012" to see 
 the diff with overlayed code coverage.

 [1] https://github.com/codecov/browser-extension/issues/22


The CodeCov support team is really nice & fast. They found the 
issue [1] and deployed it today. So the Code coverage browser 
extension is working for all PRs built on Travis starting from 
today, e.g. [2] :)

[1] https://github.com/codecov/support/issues/263
[2] https://github.com/dlang/phobos/pull/4693/files
Jul 30 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/30/2016 12:05 PM, Seb wrote:

 The CodeCov support team is really nice & fast. They found the issue [1] and
 deployed it today. So the Code coverage browser extension is working for all
PRs
 built on Travis starting from today, e.g. [2] :)

 [1] https://github.com/codecov/support/issues/263
 [2] https://github.com/dlang/phobos/pull/4693/files


[2] says [No coverage] and clicking on it says "Coverage not found"

:-(
Jul 30 2016
parent reply Seb <seb wilzba.ch> writes:
On Saturday, 30 July 2016 at 22:35:45 UTC, Walter Bright wrote:

 On 7/30/2016 12:05 PM, Seb wrote:

 The CodeCov support team is really nice & fast. They found the 
 issue [1] and
 deployed it today. So the Code coverage browser extension is 
 working for all PRs
 built on Travis starting from today, e.g. [2] :)

 [1] https://github.com/codecov/support/issues/263
 [2] https://github.com/dlang/phobos/pull/4693/files


 [2] says [No coverage] and clicking on it says "Coverage not 
 found"

 :-(


You got bad luck, 9il added a commit (so the last commit changed) 
& the build is currently running and thus "No coverage" is 
reported.

You might try another PR like:

https://github.com/dlang/phobos/pull/4647/files
Jul 30 2016
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/30/2016 3:40 PM, Seb wrote:

 You might try another PR like:

 https://github.com/dlang/phobos/pull/4647/files


Much better. Thanks!
Jul 30 2016
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/30/2016 3:40 PM, Seb wrote:

 [...]


Ok, it's time to get this rolling for Druntime, too!
Jul 30 2016
parent reply Seb <seb wilzba.ch> writes:
On Saturday, 30 July 2016 at 23:50:08 UTC, Walter Bright wrote:

 On 7/30/2016 3:40 PM, Seb wrote:

 [...]


 Ok, it's time to get this rolling for Druntime, too!


https://github.com/dlang/druntime/pull/1620 ;-)
Jul 30 2016
parent Seb <seb wilzba.ch> writes:
On Sunday, 31 July 2016 at 02:08:23 UTC, Seb wrote:

 On Saturday, 30 July 2016 at 23:50:08 UTC, Walter Bright wrote:

 On 7/30/2016 3:40 PM, Seb wrote:

 [...]


 Ok, it's time to get this rolling for Druntime, too!


 https://github.com/dlang/druntime/pull/1620 ;-)


It turns out it's not that difficult to get it working for DMD, 
too! :)

https://github.com/dlang/dmd/pull/5990
Jul 30 2016
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/28/2016 7:16 AM, Seb wrote:

 Short update - the experiment is now live. Please help to kill the uncovered
 bits in Phobos :)


Thank you very much for doing this! Raising the visibility of code coverage
will 
push towards much better unittesting of Phobos.
Jul 28 2016