Just keeping a few notes on changes that would help support this package in roxygen2:

• Duplicate @examples are joined with extra empty lines. Especially when testex tags are functionally special @examples tags, this introduces a lot of unintentional whitespace.
• @examplesIf changes the output value of the code, meaning that .Last.value is not what might be otherwise expected by tests.

  withAutoprint(1 + 2)
  .Last.value
  # == list(value = 3, visible = TRUE)
  

  instead would be preferred if the code that executes a @examplesIf statement returns only the value:

  if (<condition>) (if (getRversion() >= "3.4") (function(x) \{ x <- as.list(substitute(x))[-1]; invisible(withAutoprint(x, evaluated = TRUE)$value) \}) else force)(\{ # examplesIf}
  1 + 2
  \dontshow{\}) # examplesIf}
  

Should documentation automatically be generated when testex is run as testthat?

Without re-documenting, there's a risk that tests have been changed, but wouldn't yet be reflected. This is expected if someone is mindful about how testex works, but this is probably not a safe assumption and should probably "just work" in most cases.

Other user-facing behavior ideas:

• Should it rebuild if roxygen2 version is different?
• Should it be configurable? Parameter? DESCRIPTION option?
• Should it overwrite package docs, or just build in a temp folder? Maybe emit a warning if documentation is out of date?

Similar to roxygen2, this package will likely require some special attention for lifecycle management.

Since Rd files are generated with one version of testex, which might not necessarily be the one used when the tests are executed, there should be some graceful handling of this version mismatch.

For consistency, it should probably follow roxygen2's model of storing some data in the DESCRIPTION to record which version was used when the Rd files were generated. Then, this version can be checked against the loaded version when the tests are executed, failing gracefully when there is a version mismatch.

In such a scenario, it could silently generate new documentation in a temp folder, which it then uses for tests or just prompt the developer to re-document with the newer version.