You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the course of writing up this issue, I've realized that magrittr's "tee" pipe is a good candidate for this, but since testthat doesn't re-export this function (nor am I convinced that it necessarily should), I figured I'd float this idea anyway.
In the unit tests for a function I'm working on, I want to ensure that an object is an array, along with some other assertions. To chain these assertions, I used the pipe operator, as alluded to by testthat's documentation. It looked something like the below.
When running the test, my custom expectation kept failing, which was bewildering, since it definitely held in interactive inspection. Eventually, it dawned on me that the custom expectation was being passed is.array(f(x)) instead of f(x) itself. It's perfectly clear to me now why this is the case, but I spent some time very confused.
To help overcome this, I'm wondering if it might be suitable to introduce an expectation, something like expect_predicate(), which could evaluate a predicate for truth, returning the original object instead of TRUE/FALSE. This would enable chains where multiple orthogonal object properties are investigated while retaining the use of the "normal" pipe %>%:
I believe the second form above might require some metaprogramming to pull off properly.
If this is something that's deemed potentially of interest, I'd be happy to write up a PR (and/or proof-of-concept for trying it out), but I figured I'd open this issue before doing so.
The text was updated successfully, but these errors were encountered:
I agree with your definition of the problem; this is something that bothers me too. But I haven't yet been able to come up with an approach that I'm happy with. The problem with expect_predicate() is that you'd want want similar variants for expect_equal(), expect_s3_class(), etc, so the total number of functions would be quite high.
In the course of writing up this issue, I've realized that
magrittr
's "tee" pipe is a good candidate for this, but sincetestthat
doesn't re-export this function (nor am I convinced that it necessarily should), I figured I'd float this idea anyway.In the unit tests for a function I'm working on, I want to ensure that an object is an array, along with some other assertions. To chain these assertions, I used the pipe operator, as alluded to by
testthat
's documentation. It looked something like the below.When running the test, my custom expectation kept failing, which was bewildering, since it definitely held in interactive inspection. Eventually, it dawned on me that the custom expectation was being passed
is.array(f(x))
instead off(x)
itself. It's perfectly clear to me now why this is the case, but I spent some time very confused.To help overcome this, I'm wondering if it might be suitable to introduce an expectation, something like
expect_predicate()
, which could evaluate a predicate for truth, returning the original object instead ofTRUE
/FALSE
. This would enable chains where multiple orthogonal object properties are investigated while retaining the use of the "normal" pipe%>%
:I believe the second form above might require some metaprogramming to pull off properly.
If this is something that's deemed potentially of interest, I'd be happy to write up a PR (and/or proof-of-concept for trying it out), but I figured I'd open this issue before doing so.
The text was updated successfully, but these errors were encountered: