[ruby-core:39406] Re: RubySpec vs CRuby's test/...

Hello Charles, others,

On 2011/09/09 0:29, Charles Oliver Nutter wrote:
> On Wed, Sep 7, 2011 at 4:17 AM, NARUSE, Yui<[e-mail]>  wrote:
>> I don't think RubySpec (RSpec syntax) is beautiful.
>> I want to write assertion with declarative.
>>
>> For example I can't find which is the expectation 4 or 5.
>> Fixnum#div coerces self and the given argument to Floats and returns
>> self divided by other as Fixnum FAILED
>> Expected 4
>>   to equal 5
>
> I think this is part of the language barrier I sympathize with.

For most MRI developers, this language barrier is indeed quite high. It 
is easy for them to understand that if they want to talk to Ruby 
developers who don't speak Japanese, they have to write in English. But 
RubySpec is essentially a program, executed by a computer. Why should 
they have to write in English for the computer? If you had to choose 
between writing Ruby tests in straightforward Ruby and writing them in 
convoluted French or Japanese (or pick whatever foreign language you may 
(barely) know), which one would you prefer?

Of course some will say that the English used in RubySpec isn't for the 
computer, it's for other people who read RubySpec as a specification of 
Ruby behavior or who read the error messages. That's partially true. But 
contrary to some business-oriented application, implementers of Ruby 
should be able to deal with much simpler error messages, even if that 
may mean a tad more work when investigating the bug. Also, you may say 
that the English contains not only the actual test, but a more general 
specification. But then we get into the issue of passing the tests and 
believing (potentially wrongly, because the tests only cover individual 
cases) that an implementation conforms. That danger is lower if the 
tests are just given as tests.

[the following two lines recited for convenience]
 >> Expected 4
 >>   to equal 5

> It's a
> very terse way to say "I expected 5, but the code returned 4". I agree
> it might be a bit clearer to say "Expected 5 but got 4", but this is
> mostly a language issue; as written, it is correct, if confusing for
> you (and others).

Sorry, but here I have to disagree strongly.

It's definitely possible to read this as "Expected 4 (the result of 
executing the test code) to equal 5 (the expected result)" if one has 
used RubySpec for a while and got used to this form of output. But it's 
difficult to do so without such preconditioning.

The straightforward parsing of this sentence is "Expected (4 to equal 
5)". This is what anybody with knowledge of English syntax (but no 
knowledge of program testing) would give you. In this parsing, it's 
totally unclear which value is which.

Another way to look at it is by line. The first line says "Expected 4". 
So that must be the expected value. And it's expected to equal the 
result of executing the test, which was 5. It's not only by chance that 
in your rewording ("Expected 5 but got 4"), you switched values to move 
5 closer to Expected. This interpretation is false.

So without knowledge of RubySpec, we either don't know or get it wrong.

[I agree with Michael Klishin that this is just a minor detail, which 
can be addressed. But currently, there are quite a few of these "minor 
details", and they pile up. It would be a move forward if they were 
addressed. And there are also a few not so minor issues. See below.]


> I'm starting to feel like the RubySpec resistance boils down to "it
> has too much English in it."

It doesn't "boil down to". But "it has too much English in it, and often 
weird English" is probably one of the major points.

('weird English' includes other aspects of RubySpec such as the very 
formalized specification language (which is to some extent necessary for 
a specification), the fact that sentences appear piecemeal and the 
writer has to put them together in his/her head when writing RubySpec, 
and the use of method names that express half of a concept (.should and 
friends).)

Other major issues may be:
- Using git. Many CRuby committers are not familiar with git.
- Using RSpec-style specs rather than unit tests. This is to some
   extent a matter of taste, and that's difficult to change
   (and there have been a lot of discussions about the pros and cons
    of both approaches elsewhere, which we don't need to repeat here).
- Cognitive overhead. Fixing CRuby (often very low level C) and writing
   unit tests and writing RubySpec and using svn and git all together may
   be easy for some people, but not for many.

Regards,    Martin.