On Wed, Jun 24, 2015 at 5:42 PM, Dan Tenenbaum <dtene...@fredhutch.org> wrote: > Hello Bioconductors, > > We're pleased to announce a new shield to join the ones we rolled out in May. > > The new shield measures test coverage of a package, as determined by Jim > Hester's covr package. > > Coverage is a measure of the degree to which package code is tested by your > unit tests (https://en.wikipedia.org/wiki/Code_coverage). If you don't know > what unit tests are, read our guidelines at > http://bioconductor.org/developers/how-to/unitTesting-guidelines/ . > > These shields are on all package landing pages for software packages in > release and devel. An example shield can be seen at > > http://bioconductor.org/packages//Biobase/ > > It links to a detailed coverage report at https://codecov.io/ . > > If package coverage cannot be determined (shield value is 'unknown'), the > shield links to a section of > http://bioconductor.org/developers/how-to/unitTesting-guidelines/#coverage > explaining why > this might be. > > Note that the coverage calculation happens on our linux build machines only > and is not run as part of the nightly builds, but it is run several times a > week. Only packages whose code has changed since the last calculation are run > through covr. > > We hope this shield motivates package developers to add unit tests (if they > don't have them already) and improve their package's unit test coverage. > Refer to the covr > documentation (http://cran.r-project.org/web/packages/covr/README.html) for > more > information on how to do this. > > Questions and comments are welcome as always on the bioc-devel list.
[snare drums] ... hi-hat! Thank you very much for adding this. For folks who yet haven't looked into code coverage - it's extremely useful: * You get line-by-line coverage estimates for your R code, e.g. https://codecov.io/github/Bioconductor-mirror/DNAcopy/R/segment.R * Also for your native code, e.g. https://codecov.io/github/Bioconductor-mirror/DNAcopy/src/changepoints.f?ref=master * The line-to-line reports makes it very easy to design new tests. My experience from turning uncovered ("red") code lines into covered ("green") is that you are quite likely to discover a few more bugs along the way. I'd say it's one of the most efficient ways to find unknown bugs that I ever used. A useful rule of thumb is to always make sure that the code coverage never decreases whenever a new version is released. /Henrik > > Thanks, > Dan > > _______________________________________________ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel