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.