testthat Exercises in R: 17 Real-World Practice Problems

Explanation: expect_equal() compares numerically with a default tolerance of about 1.5e-8, which is the right choice when floating point noise could otherwise cause spurious failures (0.1 + 0.2 == 0.3 returns FALSE, but expect_equal() treats them as equal). test_that() groups related expectations under one label, returns TRUE invisibly on success, and prints a reporter line. If you need strict bit-for-bit equality, reach for expect_identical() instead.

Explanation: expect_identical() requires the values AND types to match exactly, so it would FAIL if you wrote expect_identical(years, c(2020, 2021, 2022, 2023)) because the right side is double. This is the right matcher whenever the storage type is part of the contract (integer for IDs and counts, factor for ordered categories, Date for dates). Use expect_equal() when you only care about numeric value, expect_identical() when you also care about class and storage mode.

Explanation: expect_setequal() checks set membership in both directions: every element of actual is in expected and vice versa. It does not care about order or duplicates. This is the right matcher for outputs from hash maps, unique(), dplyr::distinct(), or any operation whose order is not part of the contract. If order matters, use expect_equal() or expect_identical() instead.

Explanation: expect_true() and expect_false() are the simplest matchers, but they hide what was actually compared on failure (the report will say "is.numeric('3.14') isn't TRUE" with no context). For richer failure output, prefer dedicated matchers like expect_type(), expect_s3_class(), or expect_gt() whenever one applies. Keep expect_true()/expect_false() for boolean predicates that have no dedicated matcher.

Explanation: Shape contracts catch regressions where a downstream change accidentally drops a column, renames a slot, or returns a vector of the wrong length. expect_length() is cheaper than expect_equal(length(...), n) and produces a clearer failure message. expect_named() accepts an ignore.order = TRUE argument when name order is not part of the contract. Pair these with value checks when both the structure and the contents matter.

Explanation: expect_s3_class() checks the S3 class attribute (use expect_s4_class() for S4). expect_type() checks the underlying typeof(), which is one of "logical", "integer", "double", "character", "list", "closure", etc. An lm object is an S3 list, so both matchers should pass. This pairing is useful when refactoring: if a maintainer accidentally converts an lm object into a tibble, expect_s3_class() still passes on the wrong type while expect_type() will catch it.

Explanation: The second argument to expect_error() is a regex pattern matched against the error message; using a stable substring rather than the full string keeps the test resilient when the message is reworded slightly. For typed errors (rlang::abort with a class), prefer expect_error(..., class = "my_error_class") which checks the condition class instead of the message text and survives any message rewording. Omitting the pattern entirely just asserts that an error of any kind occurred.

Explanation: expect_warning() mirrors expect_error(): a regex pattern (or omitted to match any warning) plus an optional class argument for typed conditions. Note that calling old_api() inside expect_warning() SWALLOWS the warning, so the return value of old_api() (which is 1) is not used here. If you need both the return value AND the warning check, capture the result: result <- expect_warning(old_api(), "deprecated"). Use expect_message() for message() calls.

Explanation: expect_no_error() was added in testthat 3.0 to make "this code should not error" an explicit, named assertion rather than an implicit one. Without it, a clean run is just an unexamined side-effect of running the test, and a future refactor that introduces a regression would be detected only by a missing failure rather than a passing positive check. Sibling matchers expect_no_warning(), expect_no_message(), and expect_no_condition() make the same idea explicit for other condition types.

Explanation: Group expectations that test ONE behaviour into a single test_that() block so a failure tells a coherent story; split them into separate blocks when they test independent behaviours. The label is what appears in the test report on failure, so phrase it as a true statement about the function ("normalize standardizes correctly") rather than a procedure ("test normalize"). All expectations in a block run even if an earlier one fails, so you see every issue at once.

Explanation: Separating positive and negative cases into their own test_that() blocks gives the report two independent pass/fail signals: if the regex breaks for valid emails only, "valid emails accepted" will fail and "invalid emails rejected" will still pass, which immediately points at the bug. Lump them together when they share a setup cost (a fitted model, a temp file); split them when they probe different behaviours that can fail independently.

Explanation: purrr::walk() runs a side-effecting function for each element and returns the input invisibly, which is the right shape for fanning expectations across cases without polluting the return value. The trade-off is that on failure the report points at the line inside the lambda, not at the specific input that failed; if you need that, switch to purrr::iwalk() and embed the input value in the expectation label, or use expect_setequal(sapply(inputs, abs), expected) for shape-equivalence checks.

Explanation: Constructing the fixture INSIDE the test_that() block keeps the test self-contained: anyone reading the test sees the input and the expected output side by side, with no hidden state. For fixtures larger than a few rows or shared across many tests, factor them into a helper-*.R file in tests/testthat/ so they load once per test run. Avoid loading real CSVs in tests; the slower IO and the implicit dependency on the file existing both undermine test reliability.

Explanation: withr::local_tempdir() creates a fresh directory, sets it as the working directory, and registers a cleanup that deletes it AND restores the original working directory when the calling frame exits (the test_that() block). This is the canonical pattern for file-touching tests because it guarantees isolation: a test cannot leak files into the repo, and parallel tests cannot collide on filenames. Companion helpers withr::local_envvar(), withr::local_options(), and withr::local_dir() apply the same scope-and-restore pattern to other global state.

Explanation: Global state mutations (options, env vars, locale, RNG seed, working directory) leak between tests and cause maddening order-dependent failures. withr::local_options() solves this by automatically restoring the previous value when the calling frame exits, even on error. A common alternative is on.exit(options(old)) at the top of a test, but local_options() is shorter, harder to forget, and composes cleanly with other local_* helpers in the same block.

Explanation: expect_mapequal() is to named lists what expect_setequal() is to unnamed vectors: equality of the key-value association regardless of key order. It is the right matcher for JSON responses, named lookup tables, or any structure where the natural identity is the mapping rather than the slot positions. If element order is part of the contract (e.g., a regression coefficient vector indexed by term position), stick with expect_equal().

Explanation: expect(condition, failure_message) is the kernel of the testthat matcher protocol: it signals a pass when condition is TRUE and a fail (with failure_message) otherwise. Returning invisible(object) follows the convention of built-in matchers so custom matchers chain in a pipe (result |> expect_positive() |> expect_lt(100)). For full-featured matchers that quote their input nicely in failure reports, wrap the argument with testthat::quasi_label() to capture both the value and the unevaluated expression text.