Is there a good strategy for testing examples which should not be run by default? For instance, I have examples which get data from the Internet. If I wrap them in try() then they can be skipped if the Internet is not available, but may not be tested in cases when I would like to know about the failure. (Not to mention that the example syntax is ugly.) If I mark them \dontrun or \donttest then they are not tested. I could mark them \dontrun and then use example() but for this, in addition to run.dontrun=TRUE, I would need to specify all topics for a package, and I don't see how to do this, missing topic does not work. Wishlist: what I would really like is R CMD check --run-dontrun pkg Suggestions? Thanks, Paul
testing dontrun examples
8 messages · Spencer Graves, Hadley Wickham, Tim Keitt +3 more
Hi, Paul:
"if(!fda::CRAN())" runs code except with "R CMD check ?as-cran".
I use it so CRAN checks skip examples that (a) need the Internet or (b)
take too long for CRAN.
Hope this helps.
Spencer
On 11/26/2014 10:45 AM, Paul Gilbert wrote:
Is there a good strategy for testing examples which should not be run by default? For instance, I have examples which get data from the Internet. If I wrap them in try() then they can be skipped if the Internet is not available, but may not be tested in cases when I would like to know about the failure. (Not to mention that the example syntax is ugly.) If I mark them \dontrun or \donttest then they are not tested. I could mark them \dontrun and then use example() but for this, in addition to run.dontrun=TRUE, I would need to specify all topics for a package, and I don't see how to do this, missing topic does not work. Wishlist: what I would really like is R CMD check --run-dontrun pkg Suggestions? Thanks, Paul
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Spencer Graves, PE, PhD President and Chief Technology Officer Structure Inspection and Monitoring, Inc. 751 Emerson Ct. San Jos?, CA 95126 ph: 408-655-4567 web: www.structuremonitoring.com
On 14-11-26 02:09 PM, Spencer Graves wrote:
Hi, Paul:
"if(!fda::CRAN())" runs code except with "R CMD check ?as-cran".
I use it so CRAN checks skip examples that (a) need the Internet or (b)
take too long for CRAN.
Spencer fda::CRAN() gives TRUE on my home machine, I think because I use several variables like _R_CHECK_HAVE_MYSQL_=TRUE to control whether some tests get run. (Not all CRAN test servers have all resources.) But, more importantly, wouldn't this strategy prevent CRAN from automatically running more extensive testing of the examples if they decided to do that sometimes? Paul
Hope this helps.
Spencer
On 11/26/2014 10:45 AM, Paul Gilbert wrote:
Is there a good strategy for testing examples which should not be run by default? For instance, I have examples which get data from the Internet. If I wrap them in try() then they can be skipped if the Internet is not available, but may not be tested in cases when I would like to know about the failure. (Not to mention that the example syntax is ugly.) If I mark them \dontrun or \donttest then they are not tested. I could mark them \dontrun and then use example() but for this, in addition to run.dontrun=TRUE, I would need to specify all topics for a package, and I don't see how to do this, missing topic does not work. Wishlist: what I would really like is R CMD check --run-dontrun pkg Suggestions? Thanks, Paul
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
You can try devtools::run_examples(test = TRUE) (assuming your working directory is the top-level package directory) Hadley
On Wed, Nov 26, 2014 at 12:45 PM, Paul Gilbert <pgilbert902 at gmail.com> wrote:
Is there a good strategy for testing examples which should not be run by default? For instance, I have examples which get data from the Internet. If I wrap them in try() then they can be skipped if the Internet is not available, but may not be tested in cases when I would like to know about the failure. (Not to mention that the example syntax is ugly.) If I mark them \dontrun or \donttest then they are not tested. I could mark them \dontrun and then use example() but for this, in addition to run.dontrun=TRUE, I would need to specify all topics for a package, and I don't see how to do this, missing topic does not work. Wishlist: what I would really like is R CMD check --run-dontrun pkg Suggestions? Thanks, Paul
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
On Wed, Nov 26, 2014 at 12:45 PM, Paul Gilbert <pgilbert902 at gmail.com> wrote:
Is there a good strategy for testing examples which should not be run by default? For instance, I have examples which get data from the Internet. If I wrap them in try() then they can be skipped if the Internet is not available, but may not be tested in cases when I would like to know about the failure. (Not to mention that the example syntax is ugly.) If I mark them \dontrun or \donttest then they are not tested. I could mark them \dontrun and then use example() but for this, in addition to run.dontrun=TRUE, I would need to specify all topics for a package, and I don't see how to do this, missing topic does not work. Wishlist: what I would really like is R CMD check --run-dontrun pkg
I agree that would be nice to have. My solution was just to have a private function (pkg:::run_examples()) that runs all the examples. It has to be manually updated when adding a new example however. The devtools solution has not always worked for me when there are external dependencies (like internet download, etc.) THK
Suggestions? Thanks, Paul
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
http://www.keittlab.org/ [[alternative HTML version deleted]]
On 26/11/2014, 1:45 PM, Paul Gilbert wrote:
Is there a good strategy for testing examples which should not be run by default? For instance, I have examples which get data from the Internet. If I wrap them in try() then they can be skipped if the Internet is not available, but may not be tested in cases when I would like to know about the failure. (Not to mention that the example syntax is ugly.) If I mark them \dontrun or \donttest then they are not tested. I could mark them \dontrun and then use example() but for this, in addition to run.dontrun=TRUE, I would need to specify all topics for a package, and I don't see how to do this, missing topic does not work. Wishlist: what I would really like is R CMD check --run-dontrun pkg
We have that in R-devel, so everyone will have it next April, but there will possibly be bugs unless people like you try it out now. Duncan Murdoch
On 14-11-26 05:49 PM, Duncan Murdoch wrote:
On 26/11/2014, 1:45 PM, Paul Gilbert wrote:
Is there a good strategy for testing examples which should not be run by default? For instance, I have examples which get data from the Internet. If I wrap them in try() then they can be skipped if the Internet is not available, but may not be tested in cases when I would like to know about the failure. (Not to mention that the example syntax is ugly.) If I mark them \dontrun or \donttest then they are not tested. I could mark them \dontrun and then use example() but for this, in addition to run.dontrun=TRUE, I would need to specify all topics for a package, and I don't see how to do this, missing topic does not work. Wishlist: what I would really like is R CMD check --run-dontrun pkg
We have that in R-devel, so everyone will have it next April, but there will possibly be bugs unless people like you try it out now.
Are you anticipating my wishes now, or did you tell me this and it entered my subconscious? So far it works as advertised. Thanks, Paul
Duncan Murdoch
On 27 November 2014 at 11:23, Paul Gilbert wrote:
| On 14-11-26 05:49 PM, Duncan Murdoch wrote:
| > On 26/11/2014, 1:45 PM, Paul Gilbert wrote:
| >> Wishlist: what I would really like is R CMD check --run-dontrun pkg
| >
| > We have that in R-devel, so everyone will have it next April, but there
| > will possibly be bugs unless people like you try it out now.
|
| Are you anticipating my wishes now, or did you tell me this and it
| entered my subconscious? So far it works as advertised.
AFAICR Duncan said so in the long recent thread on the issue.
It was also reported as a change in the NEWS.Rd file, and hence communicated
via the (very useful, I find) RSS feed reporting changes in NEWS.Rd:
http://developer.r-project.org/blosxom.cgi/R-devel
Dirk
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org