Use expect_message() and expect_warning() to match specified outputs. Use expect_error() or expect_condition() to match individual errors or conditions.

expect_error(object, regexp = NULL, class = NULL, ..., info = NULL,
  label = NULL)

expect_condition(object, regexp = NULL, class = NULL, ...,
  info = NULL, label = NULL)

expect_message(object, regexp = NULL, ..., all = FALSE, info = NULL,
  label = NULL)

expect_warning(object, regexp = NULL, ..., all = FALSE, info = NULL,
  label = NULL)

Arguments

object

Object to test.

Supports limited unquoting to make it easier to generate readable failures within a function or for loop. See quasi_label for more details.

regexp

regular expression to test against.

If NULL, the default, asserts that there should be an output, a messsage, a warning, or an error, but does not test for specific value.

If NA, asserts that there should be no output, messages, warnings, or errors.

class

Instead of supplying a regular expression, you can also supply a class name. This is useful for "classed" conditions.

...

Arguments passed on to expect_match

all

Should all elements of actual value match regexp (TRUE), or does only one need to match (FALSE)

perl

logical. Should Perl-compatible regexps be used?

fixed

logical. If TRUE, pattern is a string to be matched as is. Overrides all conflicting arguments.

info

Extra information to be included in the message. This argument is soft-deprecated and should not be used in new code. Instead see alternatives in quasi_label.

label

Used to customise failure messages. For expert use only.

all

For messages and warnings, do all need to match the regexp (TRUE), or does only one need to match (FALSE)

Value

The first argument, invisibly. If expect_error() captures an error, that is returned instead of the value.

Details

Note that warnings are captured by a custom signal handler: this means that options(warn) has no effect.

Testing message vs class

When checking that code generates an error, it's important to check that the error is the one you expect. There are two ways to do this. The first way is the simplest: you just provide a regexp that match some fragment of the error message. This is easy, but fragile, because the test will fail if the error message changes (even if its the same error).

A more robust way is to test for the class of the error, if it has one. You can learn more about custom conditions at https://adv-r.hadley.nz/conditions.html#custom-conditions, but in short, errors are S3 classes and you can generate a custom class and check for it using class instead of regexp. Because this is a more reliable check, you expect_error() will warn if the error has a custom class but you are testing the message. Eliminate the warning by using class instead of regexp.

If you are using expect_error() to check that an error message is formatted in such a way that it makes sense to a human, we now recommend using verify_output() instead.

See also

Examples

# Messages ------------------------------------------------------------------ f <- function(x) { if (x < 0) message("*x* is already negative") -x } expect_message(f(-1)) expect_message(f(-1), "already negative") expect_message(f(1), NA) # You can use the arguments of grepl to control the matching expect_message(f(-1), "*x*", fixed = TRUE) expect_message(f(-1), "NEGATIVE", ignore.case = TRUE) # Warnings -------------------------------------------------------------------- f <- function(x) { if (x < 0) warning("*x* is already negative") -x } expect_warning(f(-1)) expect_warning(f(-1), "already negative") expect_warning(f(1), NA) # You can use the arguments of grepl to control the matching expect_warning(f(-1), "*x*", fixed = TRUE) expect_warning(f(-1), "NEGATIVE", ignore.case = TRUE) # Errors -------------------------------------------------------------------- f <- function() stop("My error!") expect_error(f()) expect_error(f(), "My error!") # You can use the arguments of grepl to control the matching expect_error(f(), "my error!", ignore.case = TRUE)