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
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:
but 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)
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)
Yes, thanks Jeroen - this is tracked in issue #234
Expect.onFail
allows 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-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:
but 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)The text was updated successfully, but these errors were encountered: