Thought it’d be highly worthwhile to start yet another Best Practice discussion, this time for code coverage which is far from straightforward when package developers wish to include/exclude particular (types of) files. A typical example is including some but not all src files. The tic package makes this task much easier than prior approaches (such as used in covr itself). Should tic become the Best Practice standard? What are the alternatives? In what ways might tic restrict or constrain the development of alternative approaches?
And more generally: Would it be useful for ropensci to start thinking about more structured production of Best Practice documents? There could be so many useful instances of these that would make the lives of so many people so much easier, particularly given the decreasing utility of blind web searches in a world where things change so quickly (such as the changes brought about by tic in this context). A great example is searching the web for best practice for code coverage of R packages - a highly futile exercise for which an ideal antidote would be a central repo of Best Practice docs.
What is not straightforward about passing a list of files to exclude?
I see nothing in the tic documentation or source about excluding or including files so I am not sure how it makes this any easier, it seems to just pass on arguments to covr functions.
Covr provides documentation about exclusions in both the readme and in function level documentation (?covr::exclusions). I am sorry you found this documentation hard to understand or use. issue 238 is about using a .covrignore file analogous to .gitignore to exclude files from covr, which should make this easier to maintain.
Thanks for the response Jim! I was basing my tic.R on the fact that tic just passes the arguments to covr, and that the examples in ?covr::exclusions include
# exclude whole file of R/test.R
package_coverage(exclusions = "R/test.R")
which was what I was trying to achieve. I nevertheless noted that this usage is not to be found in the readme or any other general docs I could find, although it is used in the RSQLite tic.R. Any further illumination you might be able to provide on the appropriateness or otherwise of such usage would be appreciated! Interestingly, the current tic.R precisely reversed the desired effect, by including only the file listed as exclusions, while excluding all other src files.
More general motivation was that I had been using direct after_success: codecov() on travis, but couldn’t get it to also cover the src files without a configure, which is … difficult to make compatible with the package’s current src/Makevars requirements. The straight use of codecov() seemed to drop coverage of the src/ files, with tic.R regaining it, yet in the aforementioned reverse configuration. Conclusion: Obviously not such a straightforward business, hence my suspicion that some kind of Best Practice doc would be useful.
I think part of the confusion is you were running into a covr bug in C++11 code introduced by R-3.4, which was causing the C++11 code to not have coverage tracking. I just sent a PR that should fix things using devel covr https://github.com/mpadge/bikedata/pull/27