Skip to content

Commit 7e39ff1

Browse files
clarify caller_env is from rlang (#2291)
1 parent ba05930 commit 7e39ff1

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

vignettes/custom-expectation.Rmd

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -275,7 +275,7 @@ expect_s3_object <- function(object, class = NULL) {
275275

276276
As you write more expectations, you might discover repeated code that you want to extract into a helper. Unfortunately, creating 100% correct helper functions is not straightforward in testthat because `fail()` captures the calling environment in order to give useful tracebacks, and testthat's own expectations don't expose this as an argument. Fortunately, getting this right is not critical (you'll just get a slightly suboptimal traceback in the case of failure), so we don't recommend bothering in most cases. We document it here, however, because it's important to get it right in testthat itself.
277277

278-
The key challenge is that `fail()` captures a `trace_env`, which should be the execution environment of the expectation. This usually works because the default value of `trace_env` is `caller_env()`. But when you introduce a helper, you'll need to explicitly pass it along:
278+
The key challenge is that `fail()` captures a `trace_env`, which should be the execution environment of the expectation. This usually works because the default value of `trace_env` is `rlang::caller_env()`. But when you introduce a helper, you'll need to explicitly pass it along:
279279

280280
```{r}
281281
expect_length_ <- function(act, n, trace_env = caller_env()) {

0 commit comments

Comments
 (0)