Expect.equal argument order convention

To clarify, the code was demonstrating “what if there was a bug in the implementation of (*), which the test revealed” (in this case, the bug would be “(*) squares its second argument before performing the multiplication”)

If Expect.equal takes an { expected : Expectation, actual : Expectation } record, then it can’t accept something different for fuzz than it does in the case of test - that’s just the argument it accepts everywhere!

An alternative would be to have Expect.equal for test and some other function (maybe Expect.same) that’s tailored to fuzz, and then tell everyone to use the one for the one and the other for the other, but honestly that sounds too clunky to consider seriously.

Anyway, I’m gonna duck out of this discussion. Like I said, I don’t think expected/actual is worth further exploration. :slightly_smiling_face:

1 Like