Reintroduce `Expect.true/false` with a better API?

[Janiczek]

Maybe we should make it easier to do this:

|> Expect.equal True
|> Expect.onFail "The URL should still be present in the final URL after running autolinksUrl"

by having something like

|> Expect.true { onFalse = "The URL ..." }

The previous maintainers' reasons for removing Expect.true was that it took away the spotlight from better solutions (Expect.equalLists, ...), but sometimes you just have to work with predicates. It's not always possible/practical to use the other helpers. Let's trust our users to understand when to use which solution?

[gampleman]

💯

Spitballing some ideas:

Expect.predicate : (a -> Bool) -> (a -> String) -> a -> Expectation

One issue I found making custom predicate based assertions is that to make the error message good you need to have a way of including whatever you computed into the error message, but given that you usually do this in pipelines, this becomes annoying.

\someFuzz ->
   someFuzz 
      |> SystemUnderTest.performOperation
      |> TestUtils.assertProperty
      |> Expect.equal True

to add nicer error message:

\someFuzz ->
   let 
      resultingValue =
           someFuzz 
               |> SystemUnderTest.performOperation
   in
   resultingValue
      |> TestUtils.assertProperty
      |> Expect.equal True
      |> Expect.onFail ("assertProperty failed because " ++ Debug.toString resultingValue ++ " had this specific issue")

Perhaps this API could even be improved to:

Expect.predicate : (a -> Bool) -> (String -> String) -> a -> Expectation

Where elm-test calls Debug.toString for you, so that its easier to package up custom assertions into elm packages?

\someFuzz ->
   someFuzz 
      |> SystemUnderTest.performOperation
      |> Expect.predicate TestUtils.assertProperty 
           (\repr -> 
              "assertProperty failed because " ++ rear ++ " had this specific issue"
           )