This vignette shows you how to create custom expectations that work identically to the built-in expect_
functions.
There are three main parts to writing an expectation, as illustrated by expect_length()
:
The first step in any expectation is to capture the actual object, and generate a label for it to use if a failure occur. All testthat expectations supporting quasiquotation so that you can unquote variables. This makes it easier to generate good labels when the expectation is called from a function or within a for loop.
By convention, the first argument to every expect_
function is called object
, and you capture it’s value (val
) and label (lab
) with act <- quasi_label(enquo(object))
, where act
is short for actual.
Next, you should verify the expectation. This often involves a little computation (here just figuring out the length
), and you should typically store the results back into the act
object.
Next you call expect()
. This has two arguments:
ok
: was the expectation successful? This is usually easy to write
failure_message
: What informative error message should be reported to the user so that they can diagnose the problem. This is often hard to write!
For historical reasons, most built-in expectations generate these with sprintf()
, but today I’d recommend using the glue package
Expectation functions are called primarily for their side-effects (triggering a failure), so should invisibly return their input, act$val
. This allows expectations to be chained:
Use the expectations expect_success()
and expect_failure()
to test your expectation.