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!

What’s covrpage?

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.

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.

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.

Is the covrpage report only for users?

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.

How do I publish the covrpage report?

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.

Can I get a covrpage report for any package?

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.

How do I learn more about covrpage?

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.

What did covrpage gain from Locke Data’s help?

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 the covr and testthat 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.