I have also been bitten by this order, but I can also blame myself for not reading the documentation and relying on my previous experience with other libraries, thus building an intuition that I believed was universal (when it was in fact not).
I don't think it's worth much arguing about the order of things or the "intuition" at play here, since fortunately this library comes with a manual. Very few software match our mental expectations, and even the one we write are specifically tailored for our selves of a given time and place. And as we all know, we are a stranger to our future selves.
Cheers
Hécate
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.
--
Best regards,
Daniil Iaitskov
_______________________________________________ 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.
-- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD