If you do want to communicate around tests a bit more, without cluttering the
manual, you might find the covrpage package interesting
https://yonicd.github.io/covrpage/
It creates a README in the tests folder, with test results, and it can create a
vignette with the same content.
On dj., ju
The point of an example is to provide an illustration of how the function
should be used for people who are not software developers. IMO any use of any
other functions should be absolutely minimized to reduce the cognitive overload
("you need to understand 13 other concepts before you can unders
If the point of having, say,
stopifnot(add(1, 2) == sum(c(1, 2))
is to make it explicit to the reader that your add() function gives
the same results as sum(), then I argue that is valid to use in an
example. I'm pretty sure I've used that in some of my examples. For
the purpose, there should b
Dear Richel,
The comment itself is pretty clear I think: to be accepted on CRAN you
should not use testthat tests in your examples.
I can't speak for CRAN but I'm pretty convinced this is for testing in
general.
Tests are for testing, not for demonstration. Most users of your package
will probab
Richel,
I think that feedback is important. Examples are examples first, and tests
second, as in if your examples no longer work, then maybe you need to check
your underlying code.
{testthat} tests belong in their own `tests` directory, and are used to
directly test your code and provide feedback
