Eric Hodel wrote:
> 
> On 12 May 2005, at 08:59, Daniel Berger wrote:
> 

<snip>

> 
> They're not too bad, actually.
> 
> Plus the framework handles both 1.6 and 1.8 and changes between minor/ 
> major revs quite handily.
> 
> They *do* need some loving to get up to 1.8, though.

Ok, I hadn't checked the CVS repository.  I only noticed that there 
hasn't been a new file uploaded to the project in over a year.  I 
thought it was dead.

> 
> Ryan and I are using Rubicon's Array tests for implementing MetaRuby,  
> and have noted missing tests in the suite, these include the block  form 
> of Array#fill and no tests were present for Array#zip.  I don't  know if 
> Ryan has checked in those patches yet.  Its not as if the  entire core 
> library was changed when we went from 1.6 to 1.8.
> 
> While not perfect, reinventing Rubicon because Array was missing a  
> handful of tests would be quite silly.

I don't totally understand the way tests are written/organized in 
Rubicon.  I'm also confused by the 'rubyunit' requirement.  Isn't 
everything rewritten using testunit?

<snip>

>> As things stand now we've got a single file for each core class,  but 
>> if we write comprehensive test cases for each method, putting  every 
>> test in a single file would become unwieldy.  Hence the  suggestion to 
>> have each method in its own file.
> 
> 
> I don't think so:
> 
> $ ls *Array* *String* *Hash* | xargs wc -l | sort -r
>      3267 total
>      1363 StringBase.rb
>      1224 ArrayBase.rb
>       634 HashBase.rb
>        16 TestString.rb
>        16 TestArray.rb
>        14 TestHash.rb
> 
> A 1500 line ruby file is far from unmanageable.  This also reduces  the 
> benefit for people making their own Ruby implementation.  Instead  of 
> looking through one file when implementing Array, they now have to  look 
> through over 100.

We're talking about an extremely small number of people this would 
annoy.  Having each method in its own file is much easier on my brain 
and reduces the possibility of side-effects, i.e. one test inadvertantly 
affecting another test.

>> As an aside, I would like to see Rake included in 1.8.3 and beyond  
>> because I think it could help with automating some of these things.
> 
> 
> Rubicon uses make and some custom C utilities.  Using rake would  reduce 
> the utility for people using the test suite for alternative  Ruby 
> implementations.  (JRuby uses this test suite, and so does  MetaRuby.)

Perhaps, but using Rake would (in theory) significantly reduce cross 
platform issues.  The make and custom C utilties could still be left in 
for precisely the reasons you mention, though.

<snip>

> I think you'd be better off working on Rubicon.  It has 75% of the  work 
> done for you already, has nice reports, and has many of the  
> platform/version differences spelled out.
> 
> You'll simply be reinventing the wheel by writing your own brand-new  
> test suite for Ruby.

<snip>

> I think you should take a serious look at Rubicon before rolling your  
> own.  Rubicon already has at least 75%, possibly 90% of the work you  
> need already done.  Save yourself lots of time and give it a little  
> love, and you'll have something much, much better with much, much  less 
> effort.
> 

Alright, I will look at Rubicon again. :)

Regards,

Dan