question about ZenTest

[Bill Guindon]

I ran ZenTest against the following code:

module SomeDB
class Field
attr_accessor :name, :type, :size

def initialize(name, type, size=3D0)
@name =3D name
@type =3D type
@size =3D size
end

def to_s
[@name, @type] << @size unless @size =3D=3D 0
end
end
end

And it produced the following test code:

# Code Generated by ZenTest v. 2.3.0
# classname: asrt / meth =3D ratio%
# SomeDB::Field: 0 / 2 =3D 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'?=20
Shouldn't it have also created a stub for 'test_to_s'?

TIA
--=20
Bill Guindon (aka aGorilla)

 

[Bill Guindon]

I ran ZenTest against the following code:
=20
module SomeDB
class Field
attr_accessor :name, :type, :size
=20
def initialize(name, type, size=3D0)
@name =3D name
@type =3D type
@size =3D size
end
=20
def to_s
[@name, @type] << @size unless @size =3D=3D 0
end
end
end
=20
And it produced the following test code:
=20
# Code Generated by ZenTest v. 2.3.0
# classname: asrt / meth =3D ratio%
# SomeDB::Field: 0 / 2 =3D 0.00%
=20
require 'test/unit' unless defined? $ZENTEST and $ZENTEST
=20
module TestSomeDB
class TestField < Test::Unit::TestCase
def test_name_equals
raise NotImplementedError, 'Need to write test_name_equals'
end
=20
def test_size
raise NotImplementedError, 'Need to write test_size'
end
=20
def test_size_equals
raise NotImplementedError, 'Need to write test_size_equals'
end
=20
def test_type_equals
raise NotImplementedError, 'Need to write test_type_equals'
end
end
end
=20
# Number of errors detected: 2
=20
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 -=3D Object.instance_methods(true)
the_methods -=3D Kernel.methods=20

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.

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.

--=20
Bill Guindon (aka aGorilla)

 

[Robert Klemme]

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.

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.

Kind regards

robert

 

[Bill Guindon]

=20

I ran ZenTest against the following code:

module SomeDB
class Field
attr_accessor :name, :type, :size

def initialize(name, type, size=3D0)
@name =3D name
@type =3D type
@size =3D size
end

def to_s
[@name, @type] << @size unless @size =3D=3D 0
end
end
end

And it produced the following test code:

# Code Generated by ZenTest v. 2.3.0
# classname: asrt / meth =3D ratio%
# SomeDB::Field: 0 / 2 =3D 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'? =20
After poking around in ZenTest, I'm guessing that it's caused by
method subtraction -- something like the following:
the_methods -=3D Object.instance_methods(true)
the_methods -=3D Kernel.methods =20
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.

=20
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 differ= ent
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.

=20
Maybe the algorithm that determines methods must be beefed up a bit.

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

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

Kind regards
=20
robert

--=20
Bill Guindon (aka aGorilla)