expect_snapshot_value: Snapshot testing for values

In testthat: Unit Testing for R

Snapshot testing for values

Description

Captures the result of function, flexibly serializing it into a text representation that's stored in a snapshot file. See expect_snapshot() for more details on snapshot testing.

Usage

expect_snapshot_value(
  x,
  style = c("json", "json2", "deparse", "serialize"),
  cran = FALSE,
  tolerance = testthat_tolerance(),
  ...,
  variant = NULL
)

Arguments

x	Code to evaluate.
style	Serialization style to use: json uses jsonlite::fromJSON() and jsonlite::toJSON(). This produces the simplest output but only works for relatively simple objects. json2 uses jsonlite::serializeJSON() and jsonlite::unserializeJSON() which are more verbose but work for a wider range of type. deparse uses 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.
cran	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.
tolerance	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.
variant	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.

testthat documentation built on May 29, 2024, 9:38 a.m.