Expect.onFail allows users to replace the failure message for a given test failure. From the documentation:
"something"
|> Expect.equal "something else"
|> Expect.onFail "thought those two strings would be the same"The problem with this is that failure message is computed eagerly and not lazily.
In the elm-review testing library, some of the assertions compute a fairly complex failure message which can be slow to generate. Being able to do it lazily can make the tests run much faster.
In practice, this is already possible through a custom function like this:
onFailLazy : (() -> String) -> Expectation -> Expectation
onFailLazy message expectation =
case Test.Runner.getFailureReason expectation of
Just _ ->
expectation |> Expect.onFail (message ())
Nothing ->
expectationbut this is very tricky to figure out by yourself, as Test.Runner.getFailureReason is necessary and it isn't showcased much (for good reasons).
I would like to propose that this function makes it in the library (maybe under a different name, I'm not attached to onFailLazy at all).
When mentioning this on Slack, @Janiczek mentioned that there are also places where the initial error message would be good to keep. In which case, we could make a similar function to the above available where the failure reason received from Test.Runner.getFailureReason is not ignored (or just have one function for both) (cc @edkelly303 who first mentioned it AFAIK)
onFailure : (String -> String) -> Expectation -> Expectation
Expect.onFailallows users to replace the failure message for a given test failure. From the documentation:The problem with this is that failure message is computed eagerly and not lazily.
In the
elm-reviewtesting library, some of the assertions compute a fairly complex failure message which can be slow to generate. Being able to do it lazily can make the tests run much faster.In practice, this is already possible through a custom function like this:
but this is very tricky to figure out by yourself, as
Test.Runner.getFailureReasonis necessary and it isn't showcased much (for good reasons).I would like to propose that this function makes it in the library (maybe under a different name, I'm not attached to
onFailLazyat all).When mentioning this on Slack, @Janiczek mentioned that there are also places where the initial error message would be good to keep. In which case, we could make a similar function to the above available where the failure reason received from
Test.Runner.getFailureReasonis not ignored (or just have one function for both) (cc @edkelly303 who first mentioned it AFAIK)