Snapshot testing for valuesSource:
Captures the result of function, flexibly serializing it into a text
representation that's stored in a snapshot file. See
for more details on snapshot testing.
expect_snapshot_value( x, style = c("json", "json2", "deparse", "serialize"), cran = FALSE, tolerance = testthat_tolerance(), ..., variant = NULL )
Code to evaluate.
Serialization style to use:
jsonlite::toJSON(). This produces the simplest output but only works for relatively simple objects.
jsonlite::unserializeJSON()which are more verbose but work for a wider range of type.
deparse(), which generates a depiction of the object using R code.
serialize()produces a binary serialization of the object using
serialize(). This is all but guaranteed to work for any R object, but produces a completely opaque serialization.
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.
Numerical tolerance: any differences (in the sense of
base::all.equal()) smaller than this value will be ignored.
The default tolerance is
sqrt(.Machine$double.eps), unless long doubles are not available, in which case the test is skipped.
Passed on to
waldo::compare()so you can control the details of the comparison.
NULL, results will be saved in
variantmust 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.