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
I not-uncommonly find myself writing property tests where the expected result isn't a concrete value I can check equality with, but it should pattern match a certain way.
Two (contrived) examples:
dataMyError=Error1Int | Error2Bool | Error3Intfoo::Int->EitherMyErrorBool
prop_foo_negative_throws_error1 x =
x <0==>case foo x ofLeftError1{} ->-- success
_ ->-- fail
dataMyType=MyType1 [String] | MyType2Boolbar::Int->MyType
prop_bar x =
x <0==>case bar x ofMyType1 result -> sort result === ["a", "b", "c"]
_ ->-- fail
My question is two-fold: is there a current best way to do this that I'm not seeing? If not, can we add helpers for these cases?
My current approach to the first example is to maybe do something like:
case foo x ofError1{} -> property True
result -> counterexample (show result) False-- or equivalently
counterexample (show result) $case foo x ofError1{} ->True
_ ->False
which I like better than just doing True/False, because counterexample would show the failing result, just like === would.
My current approach to the second example is using counterexample like before:
case bar x ofMyType1 result -> sort result === ["a", "b", "c"]
result -> counterexample (show result) False
it could also be done like
let result =case bar x ofMyType1 arr ->MyType1 (sort arr)
res -> res
in result ===MyType1 ["a", "b", "c"]
but that feels a bit roundabout to me.
I think both of these approaches could be improved with simple aliases provided by the QuickCheck library, something like
prop_foo_negative_throws_error1 x =
x <0==>case foo x ofLeftError1{} -> propSuccess
result -> propFail result
prop_bar x =
x <0==>case bar x ofMyType1 result -> sort result === ["a", "b", "c"]
result -> propFail result
The text was updated successfully, but these errors were encountered:
I not-uncommonly find myself writing property tests where the expected result isn't a concrete value I can check equality with, but it should pattern match a certain way.
Two (contrived) examples:
My question is two-fold: is there a current best way to do this that I'm not seeing? If not, can we add helpers for these cases?
My current approach to the first example is to maybe do something like:
which I like better than just doing
True
/False
, becausecounterexample
would show the failing result, just like===
would.My current approach to the second example is using
counterexample
like before:it could also be done like
but that feels a bit roundabout to me.
I think both of these approaches could be improved with simple aliases provided by the
QuickCheck
library, something likewhich would look like
The text was updated successfully, but these errors were encountered: