Proper successor for expect_is(M, "matrix")?

[MichaelChirico]

expect_is() is deprecated; the deprecation message mentions successors:

Sys.setenv(TESTTHAT_EDITION = 3)
expect_is(matrix(1:10), "matrix")
# Warning message:
# `expect_is()` was deprecated in the 3rd edition.
# ℹ Use `expect_type()`, `expect_s3_class()`, or `expect_s4_class()` instead

However, all of those fail where expect_is() succeeded:

expect_type(matrix(1:10), "matrix")
# Error: matrix(1:10) has type 'integer', not 'matrix'.
expect_s3_class(matrix(1:10), "matrix")
# Error: matrix(1:10) is not an S3 object
expect_s4_class(matrix(1:10), "matrix")
# Error: matrix(1:10) is not an S4 object

The core issue here is that is.object(matrix(1:10)) is FALSE even though class(matrix(1:10)) returns "matrix" or c("matrix", "array") because matrices in R somewhat strangely don't have a class set. That means testthat:::isS3(matrix(1:10)) returns FALSE.

It seems the only thing to do is:

expect_true(is.matrix(M))

Is this known / intentional behavior? I don't see anything mentioned in the documentation.

[hadley]

Yeah, I don't think of a matrix being an S3 class, so none of the existing helpers is a good fit. If for some reason I wanted to check something was a matrix, I'd probably do expect_equal(length(dim(x)), 2), but wouldn't you normally provide a stronger assertion about the actual dimensions?

[MichaelChirico]

The length(dim(.)) check would also pass a data.frame... the same applies for just checking exact dimensions. is.matrix() allows checking a function returns the right "type" of m x n object, e.g. it makes sure we get as.matrix(mtcars) and not mtcars.

[hadley]

Hmmmm, good point. But is there much benefit of expect_matrix(M) over expect_true(is.matrix(M)). I suppose you'd get A slightly nicer error message?

Maybe we could consider a generalisation of #1423 and have something like:

expect_vector(x, n = 10)
expect_matrix(m, ncol = 3, nrow = 10, type = "character")
expect_array(m, dims = c(1, 5, 10))
expect_dataframe(df, ncol = 3, nrow = 50, names = c("a", "b", "c"), ptypes = list(a = character()))`

expect_dataframe() would need a bunch of work, and expect_vector() doesn't quite fit expect_matrix() because it uses vctrs terminology/definitions rather than base, but we could probably figure that out.

[MichaelChirico]

Related: #1423 :)

[flying-sheep]

The same applies to things like expect_is(x, 'call'). Checking for type alone, like expect_type(., "language") don’t cut it, as the docs for call/is.call explain:

is.language() is also true for calls (but also for symbols and expressions where is.call() is false).

I think what’s missing is expect_mode(). expect_type(), expect_s3_class(), and expect_s4_class() are not enough to cover R’s messy type system.

See the docs for inherits (expect_is’s backend):

If the object does not have a class attribute, it has an implicit class, notably "matrix", "array", "function" or "numeric" or the result of typeof(x) (which is similar to mode(x)), but for type "language" and mode "call", where the following extra classes exist for the corresponding function calls: if, while, for, =, <-, (, {, call.

I’m not even sure if expect_mode() would cut it to e.g. check if something is a (

[hadley]

@flying-sheep IMO most of that is out of scope for testthat because I'd say it's mostly there for historical reasons. I don't think many people rely on inherits(quote({}), "{"), and if they do, they can always use it with expect_true().