I agree with the consensus that documentation is for humans, while tests
are for computers.
On Thu, Jul 16, 2020, 8:41 PM wrote:
> On Thu, 16 Jul 2020, Ben Bolker wrote:
>
> > FWIW/in defense of the OP, this is a *very* common idiom in the base R
> code
> > base. There may be some false positiv
On Thu, 16 Jul 2020, Ben Bolker wrote:
FWIW/in defense of the OP, this is a *very* common idiom in the base R code
base. There may be some false positives, but
find . -name "*.Rd" -exec grep -Fl "stopifnot(" {} \; | grep -v doc | wc
lists 187 files, e.g. from src/library/utils/man/object.si
Looks like 187 opportunities to improve clarity.
On July 16, 2020 11:30:37 AM PDT, Ben Bolker wrote:
>FWIW/in defense of the OP, this is a *very* common idiom in the base R
>code base. There may be some false positives, but
>
> find . -name "*.Rd" -exec grep -Fl "stopifnot(" {} \; | grep -v doc
FWIW/in defense of the OP, this is a *very* common idiom in the base R
code base. There may be some false positives, but
find . -name "*.Rd" -exec grep -Fl "stopifnot(" {} \; | grep -v doc | wc
lists 187 files, e.g. from src/library/utils/man/object.size.Rd
stopifnot(identical( ## assert tha
On Thu, 16 Jul 2020, Henrik Bengtsson wrote:
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
On Wed, Jul 15, 2020 at 2:22 PM Neal Fultz wrote:
> If you don't mind multi-gig docker containers, this can be helpful:
>
> https://github.com/scottyhardy/docker-wine
>
> It doesn't work with 64 bit versions of R as far as I could tell, but 32
> bit did install and start correctly in a few clicks
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
Dear R package developers,
Thanks so much for the generous responses!
In summary:
- one should usually not write tests in examples, that's what the 'tests'
folder is for
- if there is a demonstration, use a simple stopifnot, as one cannot assume a
regular reader knows about the testthat packag
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
Dear R package developers,
I would enjoy some help regarding some feedback I got on my package from a CRAN
volunteer, as I am unsure how to interpret this correctly.
This is the feedback I got (I added '[do]'):
> Please [do] not write testthat-tests in your examples.
I wonder if this is about
Hi, this is because data.table is not available as a binary package
for R-devel, on CRAN. You can tell R to build it from source like
this:
rhub::check(
platform="windows-x86_64-devel",
env_vars=c(R_COMPILE_AND_INSTALL_PACKAGES = "always")
)
Btw. please report R-ghub errors in the issue track
13 matches
Mail list logo
