Closed yonicd closed 2 years ago
Thanks @yonicd!
My opinion: I wouldn't like to have such a detailed report in the README but I can imagine it being useful for reviewers, although I still need to think (and give it a try hopefully soon!).
Thanks! Btw it is the tests dir readme not the root directory readme.
Aaah makes sense!!
the conversation with jim on the testing has been really informative for my understanding of careful testing communication.
I get the feeling that as new developers are maturing the initial inteded use of testing/coverage stats is evovling to meet broader needs.
i updated the output to make the non-passing lines pop out more, and give a disclaimer regarding what jim was getting at in the coverage stats.
@maelle have you had a chance to test drive the package. Thanks
No, not yet! Will try to do it soon! 🤞 😿
Note to self: also try covrpage::covrpage_snapshot()
.
that function is being orphaned. it got too complicated to run once i moved from testthat::test_dir
to testthat:test_check
. you would need to install the whole package and it's dependencies for it to run. I didn't think it was useful at that point.
user can just clone repo of interest and run covrpage
instead.
Running it in CI means you effectively run the tests twice, right? And with a vignette, three times?
Depends how you set up travis. If you call covr, then twice. If not then once. Vignette just copies the md output into an rmd template.
Added benefit of it though is that the user doesn’t need to remember to run it before commit. (That is worth a dbl test on a vm for me)
continuation of thread started here.
covrpage gives the package developer a simple tool to disseminate to potential users and collaborators the depth of unit testing and code coverage. Conversely, the users and collaborators can reliably verify that the developer has done due their diligence in the unit testing.
This goal is achieved by embedding the results from {covr} and {testhat} in human-readable markdown/html document containing summary tables that supply the reader links to drill into the details of testing and code coverage.
Paired with continuous integration the readme is generated independently of user interaction.
Hopefully this tool can be used by ropensci reviewers to communicate more effectively among each other and to the developers current package test/coverage status and what still needs to be worked on. And more importantly a method for end users to quickly understand what are the weak points of a package they are thinking of using.