[Haskell-cafe] order of assertEqual arguments is counterintuitive

[Arjen]

On Tuesday, March 1st, 2022 at 18:56, Daneel Yaitskov <dyaitskov at gmail.com> wrote:

> Hi List,
>
> I noticed, that I pay more attention than I should, when working with assertions, because I am not sure about argument order i.e. whether the expected value goes first or vice-versa. Does anybody have similar thought?
>
> Such subtle detail should be easy to grasp with regular practice, but I observe difficulties and I suspect that there is a logical reason for that.
>
> Unit tests appeared long time ago in Java and spread over all languages. HUnit library inherited de facto standard assert function name and signature. I don't know reasoning behind original signature.
>
> I spell "assertEqual" expression as: "Assert that x equals to y"
>
> "y" sounds like a model value (i.e. expected value).
>
> In assignments `"x <- y"` y is the model value, because it defines `"x"`.
>
> You get `"x"` - value on the left not on the right.
>
> Similar issue with test fixing - I always have to check first, that an expected value is actually one. There is no type safety preventing mixing arguments. I had to open and comprehend a source file with test, because test log is not 100% safe.

I think it is common in Haskell to have the most reusable argument(s) first. Like in this case:

shouldBeFour = assertEqual "" 4

assert1 = shouldBeFour (2 + 2)
assert2 = shouldBeFour (2 * 2)

But styles, like people, may vary between libraries.