Re: [Haskell-cafe] order of assertEqual arguments is counterintuitive

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 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 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#...

...

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.