Let's start using testthat 3?

[GegznaV]

There were changes in testthat engine 3. Please, read https://testthat.r-lib.org/articles/third-edition.html especially section "Deprecations". Then let's decide if we should start using testthat 3 syntax in the new unit tests and systematically start updating old tests to match testthat 3.

I suggest:

1. making hySpc.testthat depend on testthat v3.0.0 so that there were no unexpected things while testing on different user's machines.
2. making hyperSpec family packages to depend on the updated version of hySpc.testthat (which depends on testthat v3.0.0).
3. adding Config/testthat/edition: 3 to DESCRIPTION file of packages.
4. using only testthat 3 in the new tests.
5. if possible, updating syntax in currently existing tests.
6. adding explicit local_edition(2) to the currently existing that that we do not have time to properly update now.

What do you think, @cbeleites, @sangttruong, @bryanhanson?

[bryanhanson]

Good plan Sent from an undisclosed location - check with the NSA.

…

On Aug 1, 2021, at 2:47 PM, Vilmantas Gegzna ***@***.***> wrote:  There were changes in testthat engine 3. Please, read https://testthat.r-lib.org/articles/third-edition.html especially section "Deprecations". Then let's decide if we should start using testthat 3 syntax in the new unit tests and systematically start updating old tests to match testthat 3. I suggest: making hySpc.testthat depend on testthat v3.0.0 so that there were no unexpected things while testing on different user's machines. making hyperSpec family packages to depend on the updated version of hySpc.testthat (which depends on testthat v3.0.0). adding Config/testthat/edition: 3 to DESCRIPTION file of packages. using only testthat 3 in the new tests. if possible, updating syntax in currently existing tests. adding explicit local_edition(2) to the currently existing that that we do not have time to properly update now. What do you think, @cbeleites, @sangttruong, @bryanhanson? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[cbeleites]

I also think this is the way to go.

However, I think it has further implications - we'd likely need to move from hySpc.testthat to the usual test-*.R structure.
But according to what I found with the latest update to hySpc.testthat we may anyways want to do that: I don't see a way to get that cleanly working with devtools-based package development.

More in the meeting.

[GegznaV]

More in the meeting.

👍

[bryanhanson]

Just a gentle reminder, there is a package roxut that will allows one to put the unit tests in the same file as the function definition. Accepts testthat or tinytest. For example:

#' @tests tinytest
#' M1 <- matrix(c(0.0, 1.0, 0.0, 1.0), nrow = 2, byrow = TRUE) # parallel/colinear vectors
#' M2 <- matrix(c(0.0, 1.0, 0.0, -1.0), nrow = 2, byrow = TRUE) # anti-parallel vectors
#' M3 <- matrix(c(0.0, 1.0, 1.0, 0.0), nrow = 2, byrow = TRUE) # orthogonal vectors
#' 
#' possMeth <- c("cosine", "pearson", "abspearson", "correlation", "abscorrelation", "spearman", "kendall",
#'                 "euclidean", "maximum", "manhattan", "canberra", "binary")
#' 
#' boundMeth1 <- c("abspearson", "abscorrelation")
#' boundMeth2 <- c("pearson", "correlation", "cosine")
#' 
#' # Check that all distances by any method are positive
#' for (i in 1:length(possMeth)) {
#'   expect_true(all(rowDist(M1, possMeth[i]) >= 0.0))
#'   expect_true(all(rowDist(M2, possMeth[i]) >= 0.0))
#'   expect_true(all(rowDist(M3, possMeth[i]) >= 0.0))
#' }
#' 

[cbeleites]

@bryanhanson thanks for the reminder - I was thinking that something along these lines may be the way to go :-)

This will also allow to step down from a Dependency on hySpc.testthat which creates a whole bunch of further dependencies via testthat back to a Suggestion only.