4 ms·

The idea in TFA is to keep a function's definition, documentation, and unit tests next to each other in a single file. >Couldn't people just add expect_* tests

The idea in TFA is to keep a function's definition, documentation, and unit tests next to each other in a single file. >Couldn't people just add expect_* tests to their examples? Users can run examples with the `example` function. So if you use the `testthat` package in examples, then you should add it to your package's imports. Which means more to load with the package, but only for a small benefit that's rarely used. Also, raising warnings or errors in examples and not catching them is a no-no. The CRAN package repository will not accept a package like that. Edit: I originally wrote that this wouldn't create any examples in the final manual pages, but I was wrong.

civilized 4y ago
Ok, I think I might get it now? The tests are written down in the example, but are only run by the package developer and the results are hidden from the user? That seems like a good thing. The user wants to see the example but doesn't care about whether your test passed. The magic makes sense now too. You already need a roxygen2 header to set up the auto-generated tests, so why not call it @expect and then write equal instead of expect_equal, so as not to repeat yourself?
- masklinn 4y ago
  > Ok, I think I might get it now? The tests are written down in the example, but are only run by the package developer and the results are hidden from the user? That seems like a good thing. The user wants to see the example but doesn't care about whether your test passed. But surely the user wants to see what the result of the call is, if it's relevant? That's why rust examples (which are also doctests) include the corresponding assertions. You can hide them, but usually you don't, because e.g. showing what the result of `str::len` is is the point of having an example: https://doc.rust-lang.org/std/primitive.str.html#method.len https://doc.rust-lang.org/std/primitive.str.html#method.len Unless roxygen or Rd independently runs the code and embeds the output independent of the doctests succeeding or failing?
  - civilized 4y ago
    Right, the user wants to see the result, but doesn't care about the developer's test that the result is the expected result.

civilized 4y ago

Ok, I think I might get it now? The tests are written down in the example, but are only run by the package developer and the results are hidden from the user? That seems like a good thing. The user wants to see the example but doesn't care about whether your test passed. The magic makes sense now too. You already need a roxygen2 header to set up the auto-generated tests, so why not call it @expect and then write equal instead of expect_equal, so as not to repeat yourself?

masklinn 4y ago
> Ok, I think I might get it now? The tests are written down in the example, but are only run by the package developer and the results are hidden from the user? That seems like a good thing. The user wants to see the example but doesn't care about whether your test passed. But surely the user wants to see what the result of the call is, if it's relevant? That's why rust examples (which are also doctests) include the corresponding assertions. You can hide them, but usually you don't, because e.g. showing what the result of `str::len` is is the point of having an example: https://doc.rust-lang.org/std/primitive.str.html#method.len https://doc.rust-lang.org/std/primitive.str.html#method.len Unless roxygen or Rd independently runs the code and embeds the output independent of the doctests succeeding or failing?
- civilized 4y ago
  Right, the user wants to see the result, but doesn't care about the developer's test that the result is the expected result.