Berger, Daniel
5/12/2005 8:43:00 PM
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