[R-pkg-devel] CRAN pre-test failure due to long runtime / timeout

[Jonas Kurle]

Dear Ivan and Dirk,

Thank you both for your suggestions and your help.

For now, I will simply skip the automatic unit testing on CRAN. My 
submission to winbuilder is now successful for all versions of R.

In the long run, I might move away from testthat to have more 
flexibility with respect to debugging and being able to see in more 
detail what is going on. I also received a hint from another user 
(thanks Johannes!) who ran my tests locally on their Debian system, 
where the tests did not time out but eventually produced an error. It 
turns out that some of my tests / functions work slightly differently on 
different platforms, so I can now adjust these tests to be 
platform-specific.

Thanks again and best wishes,
Jonas


Am 23.07.2022 um 07:21 schrieb Ivan Krylov:
> On Fri, 22 Jul 2022 21:09:15 +0100
> Jonas Kurle <mail using jonaskurle.com> wrote:
>
>> Can anyone advise me what to do?
> I see you're using testthat. Is there a way to make it produce verbose
> output for every test during their runtime? As far as I know, testthat
> tests look like a single test to R CMD check which only outputs
> everything after it's done (or an error occurs). Since the R process is
> terminated on timeout, it doesn't get a chance to handle an error and
> print anything.
>
> One way I see is relatively time-consuming, but so is blindly playing
> skip_on_cran with individual tests and resubmitting jobs to
> win-builder. If you move your tests from tests/testthat/*.R into
> tests/*.R (and adjust them to work outside the testthat harness if
> necessary), R should be able to tell you which *.R file times out
> and show you the approximate location where it was terminated.
>
> Alternatively, you could try instrumenting your tests with debugging
> print commands and see if any of them end up in 00check.log, but I
> think that testthat uses capture.output to declutter the console when
> running tests, which, sadly, ends up interfering with your ability to
> debug the problem in this case.
>