Don't test against a live website for most of your testing... use recorded or simulated input. If your package functional interface doesn't allow for that, then re-factor it so it does.
For those tests that actually have to interact with the live website, only run them if you know you are not on CRAN. The testthat package has support for this if you don't want to roll your own. On November 30, 2020 10:45:01 AM PST, "Ayala Hernandez, Rafael" <r.ayal...@imperial.ac.uk> wrote: >Dear all, > >My package openSkies includes a set of functions to retrieve >information from the OpenSky API. > >The examples for these functions can, on rare occassions, take >anomously longer times to complete than usually because of issues on >the API side. > >I have already included a timeout parameter to prevent endless attempts >to retrieve the result when, for example, the API is down for >maintenance. > >I have recently been asked by CRAN to reduce the execution time of each >example to below 5 s. In order to do this, I can set the timeout >parameter to something below 5s, and return NULL and a message >indicating the resource is not currently available. However, I think >this might not be the best option for examples that demonstrate >important functionalities to users. > >Therefore, I was wondering if there is anyway to set up the timeout >parameter to a different value than usual based on the condition that >examples are being run as part of R CMD check? > >Thanks a lot in advance > >Best wishes, > >Rafa > > [[alternative HTML version deleted]] > >______________________________________________ >R-package-devel@r-project.org mailing list >https://stat.ethz.ch/mailman/listinfo/r-package-devel -- Sent from my phone. Please excuse my brevity. ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
