Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add lazy version of Expect.onFail #239

Open
jfmengels opened this issue Jan 12, 2025 · 1 comment
Open

Add lazy version of Expect.onFail #239

jfmengels opened this issue Jan 12, 2025 · 1 comment

Comments

@jfmengels
Copy link

jfmengels commented Jan 12, 2025

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 ->
            expectation

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)

onFailure : (String -> String) -> Expectation -> Expectation
@edkelly303
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants