These snapshotting functions are questioning because they were developed
before expect_snapshot()
and we're not sure that they still have a
role to play.
expect_snapshot_output()
captures just output printed to the console.
expect_snapshot_error()
captures an error message and
optionally checks its class.
expect_snapshot_warning()
captures a warning message and
optionally checks its class.
expect_snapshot_output(x, cran = FALSE, variant = NULL)expect_snapshot_error(x, class = "error", cran = FALSE, variant = NULL)
expect_snapshot_warning(x, class = "warning", cran = FALSE, variant = NULL)
Code to evaluate.
Should these expectations be verified on CRAN? By default, they are not, because snapshot tests tend to be fragile because they often rely on minor details of dependencies.
If non-NULL
, results will be saved in
_snaps/{variant}/{test.md}
, so variant
must be a single string
suitable for use as a directory name.
You can use variants to deal with cases where the snapshot output varies and you want to capture and test the variations. Common use cases include variations for operating system, R version, or version of key dependency. Variants are an advanced feature. When you use them, you'll need to carefully think about your testing strategy to ensure that all important variants are covered by automated tests, and ensure that you have a way to get snapshot changes out of your CI system and back into the repo.
Class of expected error or warning. The expectation will
always fail (even on CRAN) if an error of this class isn't seen
when executing x
.