[Haskell-cafe] order of assertEqual arguments is counterintuitive

[Evan Laforge]

I've always done `equal (thingToTest args) expectedValue` just as a
habit, but it's usually the right order for me in haskell because
`equal (f args) $ big complicated value`.  It seems more common that
the expected value is larger than arguments are.  But I don't think I
chose it due to that, it was probably that I also write `if mode ==
Whatever then ...` with the constant on the right, and that's probably
some kind of "mental handedness" habit.

But I've also usually written my own test frameworks, so I got to make
the rules.  If I use someone else's, then I try to follow whatever
convention they put forth.  I'm not sure it's ever mattered much
though, because as soon as I see an error I go to the line that
generated it, and then it's pretty clear if the left or right side is
the expected value.


On Tue, Mar 1, 2022 at 2:50 PM David Feuer <david.feuer at gmail.com> wrote:
>
> I think newtypes are awkward here. Better to use a record to get "named arguments":
>
> data ExpAct a = ExpAct
>   { expected :: a
>   , actual :: a
>   }
>
> assertSame
>   :: HasCallStack
>   => (Eq a, Show a)
>   => String
>   -> ExpAct a
>   -> Assertion
> assertSame s ExpAct{expected=e, actual=a} = assertEqual s e a
>
> Now you can write things like
>
> assertSame "whatever" ExpAct{expected=4, actual=x}
>
> On Tue, Mar 1, 2022, 2:38 PM Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
>>
>> On Tue, Mar 01, 2022 at 12:56:02PM -0500, Daneel Yaitskov wrote:
>>
>> > 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?
>>
>> The documentation is quite clear:
>>
>>     https://hackage.haskell.org/package/HUnit-1.6.2.0/docs/Test-HUnit-Base.html#v:assertEqual
>>
>> > 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.
>> >
>> > I spell "assertEqual" expression as:  "Assert that x equals to y"
>> > "y" sounds like a model value (i.e. expected value).
>>
>> As a combinator that can be curried,
>>
>>     -- Check variable given against fixed wanted
>>     assertEqual prefix wanted :: (Eq a, Show a) => a -> Assertion
>>
>> is I think more useful than:
>>
>>     -- Check variable wanted against fixed given.
>>     assertEqual prefix given :: (Eq a, Show a) => a -> Assertion
>>
>> > 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.
>>
>> The test works either way of course, the only thing that changes is the
>> error message on failure.  You could implement a type-safe wrapper:
>>
>>     newtype Given a  = Given a
>>     newtype Wanted a = Wanted a
>>
>>     checkEq :: (Eq a, Show a) => String -> Given a -> Wanted a -> Assertion
>>     checkEq prefix (Given x) (Wanted y) = assertEqual prefix y x
>>
>> Then always call via:
>>
>>     checkEq "Oops" (Given (2 + 2)) (Wanted 5)
>>
>> --
>>     Viktor.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.