On 7/13/05, Robert Klemme <bob.news / gmx.net> wrote:
> 
> "Bill Guindon" <agorilla / gmail.com> schrieb im Newsbeitrag
> news:67a2229205071312286a9e19d9 / mail.gmail.com...
> On 7/13/05, Bill Guindon <agorilla / gmail.com> wrote:
> > I ran ZenTest against the following code:
> >
> > module SomeDB
> >   class Field
> >     attr_accessor :name, :type, :size
> >
> >     def initialize(name, type, size=0)
> >       @name = name
> >       @type = type
> >       @size = size
> >     end
> >
> >     def to_s
> >       [@name, @type] << @size unless @size == 0
> >     end
> >   end
> > end
> >
> > And it produced the following test code:
> >
> > # Code Generated by ZenTest v. 2.3.0
> > #                 classname: asrt / meth =  ratio%
> > #             SomeDB::Field:    0 /    2 =   0.00%
> >
> > require 'test/unit' unless defined? $ZENTEST and $ZENTEST
> >
> > module TestSomeDB
> >   class TestField < Test::Unit::TestCase
> >     def test_name_equals
> >       raise NotImplementedError, 'Need to write test_name_equals'
> >     end
> >
> >     def test_size
> >       raise NotImplementedError, 'Need to write test_size'
> >     end
> >
> >     def test_size_equals
> >       raise NotImplementedError, 'Need to write test_size_equals'
> >     end
> >
> >     def test_type_equals
> >       raise NotImplementedError, 'Need to write test_type_equals'
> >     end
> >   end
> > end
> >
> > # Number of errors detected: 2
> >
> > Any idea why it didn't create stubs for 'test_name' and 'test_size'?
> > Shouldn't it have also created a stub for 'test_to_s'?
> 
> > After poking around in ZenTest, I'm guessing that it's caused by
> > method subtraction -- something like the following:
> >   the_methods -= Object.instance_methods(true)
> >   the_methods -= Kernel.methods
> 
> > Which explains why it ignored 'to_s', and had issues with 'name' and
> > 'size', although I still find it strange that it built the '_equals'
> > methods for them.
> 
> As far as I can see stubs for #size are in place.  Did you mean #type
> instead?  Btw, #type is not a good method name, as it's the old alias for
> #class - so it may break some code if your class returns something different
> than a Class instance.

Yep, mixed up #size and #type.  It seems safe in this case, it's just
a plain text attribute, but I do try to keep that in mind.

> > Any suggestions on avoiding this?  The obvious answer is not to use
> > methods with the same name as Object or Kernel methods, but that seems
> > a bit harsh.
> 
> Maybe the algorithm that determines methods must be beefed up a bit.

Seems that way, but I can see why he took that route.  

Even with this one little oddity, it's a great library.

> Kind regards
> 
>     robert

-- 
Bill Guindon (aka aGorilla)