Is there a recommended way to inspect coverage of your scripts by the package unit tests? The Bioconductor HOWTO on unit testing for developers is very helpful for getting unit tests set up for a package: http://www.bioconductor.org/developers/unitTesting-guidelines/ The guidelines don't mention the code inspection feature of RUnit, the inspect() function, which analyzes the coverage of each line of script ( http://cran.r-project.org/web/packages/RUnit/vignettes/RUnit.pdf, section 2.2). It would be great to have this html report just appear in packagename.Rcheck/tests after running R CMD check, but any solution would do. Thank you, Levi [[alternative HTML version deleted]]

On Sat, Aug 11, 2012 at 2:58 PM, Levi Waldron <lwaldron.research at="" gmail.com=""> wrote: > Is there a recommended way to inspect coverage of your scripts by the > package unit tests? Not particularly. > The Bioconductor HOWTO on unit testing for developers > is very helpful for getting unit tests set up for a package: > > http://www.bioconductor.org/developers/unitTesting-guidelines/ > > The guidelines don't mention the code inspection feature of RUnit, the > inspect() function, which analyzes the coverage of each line of script ( > http://cran.r-project.org/web/packages/RUnit/vignettes/RUnit.pdf, section > 2.2). It would be great to have this html report just appear in > packagename.Rcheck/tests after running R CMD check, but any solution would > do. If you call inspect() in your unit tests, the results (assuming you print them out with printHTML.trackInfo(); see the example at ?inspect) will end up in packagename.Rcheck/tests/results/index.html (unless you specify a different output directory with the baseDir argument to printHTML.trackInfo(). Dan > > Thank you, > Levi > > [[alternative HTML version deleted]] > > _______________________________________________ > Bioconductor mailing list > Bioconductor at r-project.org > https://stat.ethz.ch/mailman/listinfo/bioconductor > Search the archives: http://news.gmane.org/gmane.science.biology.informatics.conductor

Hi Levi, The RUnit inspector looks like a fine piece of work, but as I read section 2.2 of RUnit.pdf, it seems to be a programmer-exploration tool, not an automated build-time assessment and reporting tool: The Code Inspector is an additional tool for checking detailed test case cover-age and getting profiling information. It records how often a code line will be executed. We utilise this information for improving our test cases, because we can identify code lines not executed by the current test case code. The Code Inspector is able to handle S4 methods. During the development of the Code Inspector, we noticed, that the syntax of R is very flexible. Because our coding philosophy has an emphasis of maintenance and a clear style, we developed style guides for our R coding. Therefore, one goal for the Code Inspector was to handle our coding styles in a correct manner. This leads to the consequence that not all R expression can be handled correctly. In our implementation the Code Inspector has two main functional parts. The first part is responsible for parsing and modifying the code of the test function. The second part, called the Tracker, holds the result of the code tracking. The result of the tracking process allows further analysis of the executed code. If I misjudge this, or if automated coverage calculations should appear in RUnit sometime in the future, then coverage reports would be well worth having. - Paul