similar to: Testthat and global environments in R packages on CRAN

Displaying 20 results from an estimated 2000 matches similar to: "Testthat and global environments in R packages on CRAN"

2015 Feb 08
1
Testthat and global environments in R packages on CRAN
Hi! The problem is that the test environment inherits from the global environment. See https://github.com/hadley/testthat/blob/master/R/test-files.r The students labs are simply an R script file. Say that they have an assignment to calculate sqrt(2) and store it in variable a. In the same session they should be able to test the script file when they are done (using a function mark_my_file() in
2015 Feb 08
0
Testthat and global environments in R packages on CRAN
On 08/02/2015 8:22 AM, M?ns Magnusson wrote: > Hi! > > Im currently developing an R package to automatically give students > feedback on programming assignments in R. I use the testthat package as an > engine for the unit testing and do a wrapper to make the automatic marking > easy for the students. > > One function (called mark_my_file() ) will mark the students lab
2017 Sep 17
2
R-devel r73293 and the testthat package
Hello, Windows R-devel no longer lets me use testthat even though the CRAN checks are pretty much clean. I have copied my session output below. Will R Under development (unstable) (2017-09-16 r73293) -- "Unsuffered Consequences" Copyright (C) 2017 The R Foundation for Statistical Computing Platform: x86_64-w64-mingw32/x64 (64-bit) R is free software and comes with ABSOLUTELY NO
2019 Aug 12
1
ALTREP package interaction with testthat
Hi I found a weird problem in testthat while working with an ALTREP package. The package name is AltWrapper. My ALTREP serialize function is called even when I'm trying to serialize a non-ALTREP object. Here is an example ``` context("altrep") length_func<-function(x){ return(length(x)) } setAltClass(className = "test", classType = "real")
2023 Jan 10
1
rhub vs. CRAN fedora-*-devel, using armadillo & slapack
On 10/01/2023 4:07 p.m., Sebastian Meyer wrote: > Am 10.01.23 um 21:28 schrieb Duncan Murdoch: >> On 10/01/2023 2:05 p.m., Ivan Krylov wrote: >>> On Tue, 10 Jan 2023 16:27:53 +0000 >>> RICHET Yann <yann.richet at irsn.fr> wrote: >>> >>>> In facts, 10 threads are asked by armadillo for some LinAlg, which >>>> backs to two threads as
2023 Jan 11
2
rhub vs. CRAN fedora-*-devel, using armadillo & slapack
Thank you all, for these advices. So I try to fix OMP_THREADS, cleanup tests, and display explicitly what test is running by moving in tests/ instead of tests/testthat/... Next step should be to investigate blocking test using a reporter (maybe "list"). For now, waiting for CRAN results... Yann -----Message d'origine----- De?: Duncan Murdoch <murdoch.duncan at gmail.com>
2023 Jan 10
1
rhub vs. CRAN fedora-*-devel, using armadillo & slapack
Am 10.01.23 um 21:28 schrieb Duncan Murdoch: > On 10/01/2023 2:05 p.m., Ivan Krylov wrote: >> On Tue, 10 Jan 2023 16:27:53 +0000 >> RICHET Yann <yann.richet at irsn.fr> wrote: >> >>> In facts, 10 threads are asked by armadillo for some LinAlg, which >>> backs to two threads as warned. >> >> I think you're right about your tests de-facto
2018 May 30
1
CRAN checks give errors when no tests are included
Dear all, as a follow-up to the question asked on R-package-devel (see link below): Someone sent a package to CRAN with a few problems. There's more things wrong with the submission, but one thing that really caught my eye was the following error: Warning message: running command '"C:/PROGRA~1/R/R-33~1.2/bin/x64/R" CMD BATCH --vanilla "testthat.R"
2023 Jan 10
1
rhub vs. CRAN fedora-*-devel, using armadillo & slapack
On 10/01/2023 2:05 p.m., Ivan Krylov wrote: > On Tue, 10 Jan 2023 16:27:53 +0000 > RICHET Yann <yann.richet at irsn.fr> wrote: > >> In facts, 10 threads are asked by armadillo for some LinAlg, which >> backs to two threads as warned. > > I think you're right about your tests de-facto using two threads, but > it might be a good idea to _default_ to up to
2023 Jan 10
1
rhub vs. CRAN fedora-*-devel, using armadillo & slapack
On Tue, 10 Jan 2023 16:27:53 +0000 RICHET Yann <yann.richet at irsn.fr> wrote: > In facts, 10 threads are asked by armadillo for some LinAlg, which > backs to two threads as warned. I think you're right about your tests de-facto using two threads, but it might be a good idea to _default_ to up to two threads in tests and examples. This is especially valuable for third-party
2020 Jan 14
1
CRAN check fails if website is unavailable on Fedora platforms
Hi all, I maintain the package ?qrandom? which is based on a web API. In last time the testthat tests failed because the website was down. I implemented the following code in v1.2.2 to ensure that tests are only run if the website is accessible and to avoid the CRAN checks to fail: > library(testthat) > library(qrandom) > check_qrng <- function(){ > tryCatch( >
2023 Jan 10
2
rhub vs. CRAN fedora-*-devel, using armadillo & slapack
Thank you for your answer. In facts, 10 threads are asked by armadillo for some LinAlg, which backs to two threads as warned. But I cannot imagine this costs so much time just for that... A deeper analysis of time spent seems to point that a large time was mainly spent on testthat and Rcpp dependencies compilation... But other recent packages depending on these also are not spending so much time.
2011 Dec 30
0
testthat 0.6
# testthat Testing your code is normally painful and boring. `testthat` tries to make testing as fun as possible, so that you get a visceral satisfaction from writing tests. Testing should be fun, not a drag, so you do it all the time. To make that happen, `testthat`: * Provides functions that make it easy to describe what you expect a function to do, including catching errors, warnings and
2011 Dec 30
0
testthat 0.6
# testthat Testing your code is normally painful and boring. `testthat` tries to make testing as fun as possible, so that you get a visceral satisfaction from writing tests. Testing should be fun, not a drag, so you do it all the time. To make that happen, `testthat`: * Provides functions that make it easy to describe what you expect a function to do, including catching errors, warnings and
2010 Sep 01
0
testthat: version 0.3
# testthat Testing your code is normally painful and boring. `testthat` tries to make testing as fun as possible, so that you get a visceral satisfaction from writing tests. Testing should be fun, not a drag, so you do it all the time. To make that happen, `testthat`: * Provides functions that make it easy to describe what you expect a function to do, including catching errors, warnings and
2010 Sep 01
0
testthat: version 0.3
# testthat Testing your code is normally painful and boring. `testthat` tries to make testing as fun as possible, so that you get a visceral satisfaction from writing tests. Testing should be fun, not a drag, so you do it all the time. To make that happen, `testthat`: * Provides functions that make it easy to describe what you expect a function to do, including catching errors, warnings and
2015 May 04
2
Print output during long tests?
I am the author of R package animint which uses testthat for unit tests. This means that there is a single test file (animint/tests/testthat.R) and during R CMD check we will see the following output * checking tests ... Running ?testthat.R? I run these tests on Travis, which has a policy that if no output is received after 10 minutes, it will kill the check. Because animint's testthat
2016 Jan 18
4
r-devel @ Travis
Hi! I'm developing R packages and use Travis CI for continous integration. When submitting to CRAN Im suggestet to test the package using the latest R-devel. I would like that all test where run using Travis. Is there anyone who knows if this is possible to run travis test using the latest r-devel? -- Regards M?ns ============================ M?ns Magnusson 070 - 588 97 15 mons.magnusson
2010 Nov 15
2
Trying to understand the search path and namespaces
Hi all, I'm trying to understand how the search path and namespaces interact. For example, take the devtools package which suggests the testthat package. Here's what the search path looks like after I load each of those packages: > library(devtools) > search() [1] ".GlobalEnv" "package:devtools" "package:stats" [4]
2015 Apr 19
4
running unit tests on the stringr package
I am trying to learn how to run the unit tests in the stringr package and have the following questions. 1) The r-cran-stringr package does not suggest/depend on the r-cran-testthat package . Would it make sense to add such a thing since after all the tests in /usr/lib/R/site-library/stringr/tests rely on testthat package? 2) I am getting the following error when trying to run the unit tests %