<div dir="auto">I think newtypes are awkward here. Better to use a record to get "named arguments":<div dir="auto"><br></div><div dir="auto">data ExpAct a = ExpAct</div><div dir="auto"> { expected :: a</div><div dir="auto"> , actual :: a</div><div dir="auto"> }</div><div dir="auto"><br></div><div dir="auto">assertSame</div><div dir="auto"> :: HasCallStack<span style="white-space:pre"> </span> <br></div><div dir="auto"> => (Eq a, Show a)<span style="white-space:pre"> </span> </div><div dir="auto"> => String<span style="white-space:pre"> </span></div><div dir="auto"> -> ExpAct a</div><div dir="auto"> -> Assertion<span style="white-space:pre"> </span><br></div><div dir="auto">assertSame s ExpAct{expected=e, actual=a} = assertEqual s e a</div><div dir="auto"><br></div><div dir="auto">Now you can write things like</div><div dir="auto"><br></div><div dir="auto">assertSame "whatever" ExpAct{expected=4, actual=x}</div><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Tue, Mar 1, 2022, 2:38 PM Viktor Dukhovni <<a href="mailto:ietf-dane@dukhovni.org">ietf-dane@dukhovni.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Mar 01, 2022 at 12:56:02PM -0500, Daneel Yaitskov wrote:<br>
<br>
> I noticed, that I pay more attention than I should, when working with<br>
> assertions, because I am not sure about argument order i.e. whether the<br>
> expected value goes first or vice-versa. Does anybody have similar thought?<br>
<br>
The documentation is quite clear:<br>
<br>
<a href="https://hackage.haskell.org/package/HUnit-1.6.2.0/docs/Test-HUnit-Base.html#v:assertEqual" rel="noreferrer noreferrer" target="_blank">https://hackage.haskell.org/package/HUnit-1.6.2.0/docs/Test-HUnit-Base.html#v:assertEqual</a><br>
<br>
> Such subtle detail should be easy to grasp with regular practice, but I<br>
> observe difficulties and I suspect that there is a logical reason for that.<br>
> <br>
> I spell "assertEqual" expression as: "Assert that x equals to y"<br>
> "y" sounds like a model value (i.e. expected value).<br>
<br>
As a combinator that can be curried, <br>
<br>
-- Check variable given against fixed wanted<br>
assertEqual prefix wanted :: (Eq a, Show a) => a -> Assertion<br>
<br>
is I think more useful than:<br>
<br>
-- Check variable wanted against fixed given.<br>
assertEqual prefix given :: (Eq a, Show a) => a -> Assertion<br>
<br>
> Similar issue with test fixing - I always have to check first, that an<br>
> expected value is actually one. There is no type safety preventing mixing<br>
> arguments.<br>
<br>
The test works either way of course, the only thing that changes is the<br>
error message on failure. You could implement a type-safe wrapper:<br>
<br>
newtype Given a = Given a<br>
newtype Wanted a = Wanted a<br>
<br>
checkEq :: (Eq a, Show a) => String -> Given a -> Wanted a -> Assertion<br>
checkEq prefix (Given x) (Wanted y) = assertEqual prefix y x<br>
<br>
Then always call via:<br>
<br>
checkEq "Oops" (Given (2 + 2)) (Wanted 5)<br>
<br>
-- <br>
Viktor.<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.<br></blockquote></div></div>