On Tue, Oct 7, 2008 at 10:53 PM, Austin Ziegler <halostatue / gmail.com> wrote:
> On Tue, Oct 7, 2008 at 10:53 PM, Michael Guterl <mguterl / gmail.com> wrote:
>> On Tue, Oct 7, 2008 at 10:40 PM, Ryan Davis <ryand-ruby / zenspider.com> wrote:
>>> On Sep 25, 2008, at 05:26 , Austin Ziegler wrote:
>>>> When I write a test, I'm not
>>>> *refuting* that something isn't equal, I'm making a positive assertion
>>>> of inequality (yes, that sounds odd, but it's exactly what I'm doing).
>>> I know not to get into an email argument with you, but for the sake of
>>> ruby-core, I have to say that I find this semantics game to be completely
>>> arbitrary and ridiculous.
>> I think Austin brings up a good point with his argument for semantics.
>> Can you provide a compelling argument for the change?
>
> I can actually see Ryan's point of saying that "refute_equal a, b"
> being clearer than "assert_not_equal a, b". If I were writing an
> English sentence, I'd definitely use the former sort of construct ("I
> refute that a and b are equivalent") rather than the latter sort of
> construct ("I assert that a and b are not equal").

Wow, this feels awkward to me.

  refute_equal 1, 2

Now, I look at this and I'm asking myself, what is it supposed to do?
To figure it out, I try putting it into words. "I refute that 1 equals
2". Ok, so, uhm, 1 does not equal 2, and I am refuting that, so I
guess that means that it doesn't cause a test failure. Right?

  refute_equal 1, 1  # I refute that 1 equals 1.

Now, parsing this one, I'm refuting the equivalence of 1 and 1. Ok, so
they are equal, and I am refuting their equality, which is the same
same asserting their inequality. So, this one fails too, right?

Man, this is confusing.
I can see myself struggling with this syntax for years to come.

> I don't see unit test assertions as English sentences, though. I see
> them as hypotheses to be verified or falsified depending on how well
> I've written my code to satisfy them.

Yes, but sometimes I need to put it into words to understand it. I
like it when my code maks obvious sense. My guidline for making code
choices is how fast the code can be understood when I look at it cold.




-- 
Jim Freeze