In this post, we shall explore the first R package that received Locke Data’s new support, covrpage
by Jonathan Sidi! With this nifty package you can better communicate the unit testing completeness and goodness of your package!
Trust is earned not inherited importedFrom. Now that you’ve built a cool package, you want potential users to trust it so that they might adopt it. So how can you build trust in your software? Unit testing is one of the components building trustworthiness of your package. Imagine you’re at the point where you’ve tested most lines of your code with thorough assertions, including checks of edge cases. Proof of that hard work will be a high test coverage, that potential users of your package might notice thanks to a bright green coverage badge.
Green coverage badge for the rfm package
But how would they know your tests are thorough? That’s what covrpage
helps you with, by creating a summary report of your tests that goes beyond the coverage percentage.
Tests summary report for the rfm package
This way, potential users can see at a glance how good the unit testing of your package is. This report can be used as a README for the tests folder, as well as a vignette in the pkgdown
website and/or CRAN page of a package.
No, it can also inform your work on your package, by helping you track progress of the unit tests you’re working on, and it can show to potential contributors where help is needed.
There are two places where you can keep the covrpage
report, and it’s advised to use both since they will get seen by different readers:
-
A README for the tests/ folder, which is the original report location.
covrpage::covrpage()
sets it up. Target audience: users or collaborators browsing the GitHub repo of your package, possibly guided there by a badge in the main README. -
A vignette, that’ll get inserted into the
pkgdown
website of your package, and the CRAN page if/when your package is released on CRAN.covrpage::use_covrpage_vignette()
sets it up. Target audience: users reading the rendered documentation.
In both cases, you can also ensure the report stays up-to-date by having it deployed from Travis every time you push to your repository.
See a new package on GitHub that you would like to use, but need to feel more comfortable before committing to it? You can run covrpage_snapshot()
to create a report in a sterile environment, without affecting your .libPaths
, and make a more informed decision wether to install the package.
For more information see the snapshots vignette.
To read more about getting started with covrpage
in your own package in a few lines of code only, we recommend checking out the “get started” vignette. It explains more how to setup the Travis deploy, mentions which functions power the covrpage
report, and gives more motivation for using covrpage
.
And to learn how the information provided by covrpage
should be read, read the “How to read the covrpage
report” vignette.
covrpage logo
As announced recently, we at Locke Data will help a package a month get more widely adopted. In the case of covrpage
, our main input was:
-
the creation of a nice logo by Oz Locke. The logo highlights that
covrpage
extends thecovr
andtestthat
packages by helping the user inspect their results. -
the improvement of documentation, in particular vignettes and the README, to make it clearer why potential users should care about
covrpage
. -
exploration of Travis deploy of the report via the
tic
package, to make the setup smoother.
Thanks Jonathan for letting us get involved for your package, and good luck with future development! And if you think your broadly applicable package could benefit from our support getting your package into shape then apply now.