Ryan Davis wrote:
> On May 22, 2006, at 1:36 PM, Jim Weirich wrote:
> 
>> The problem with subclassing is that it doesn't combine well with  
>> other
>> potential Test::Unit add-ins.  (For that matter, I suspect the  
>> patch way
>> doesn't combine well either, but I haven't looked at the details).
> 
> "potential add-ins" is a red flag for YAGNI.
> 
>> For example, I have a Test::Unit::TestCase mod that allows FlexMock
>> objects to be automatically verified at the end of a test case.  If I
>> make this a sub-class, then Brett can't use my FlexMock subclass with
>> his Watir subclass.
> 
> I guess I don't understand. Is your FlexMock mod a subclassed
> testcase as well? If not, then where is the conflict?

Some background ... before last week, to use FlexMock in a test case, 
you would say:

(I)
   def test_blah
     FlexMock.use("mockname") do |mock|
       mock.blah.blah.blah
       # test goes here
     end
   end

The block usage ensures that verification is run on the mock at the end 
of the test.  Although idiomatic Ruby, the block made (a) multiple mocks 
awkward, and (b) the ability to refactor common mock creation/setup into 
a separate method awkward.

Neither (a) nor (b) were show stoppers, just rather unsatisfying.  What 
I wanted to be able to write was:

(II)
   def test_blah
     mock = flexmock("mockname")
     mock.blah.blah.blah
     # test goes here
   end

Now multiple mocks and special mock creation methods are trivial.  To 
get to (II), I had to override teardown.  I can use either a subclass or 
module to do this.  My choice was to use a module ...

However ...

Your suggestion to Brett was to use a subclass.  If I had followed the 
suggestion and used a subclass (rather than a module), then my add-in 
and Brett's add-in could not interoperate.  So, my counter suggestion to 
Brett was to use a module as well (rather than a subclass).

> Your extension seems to be orthogonal to
> TestCase, and so belongs in a module to be mixed in wherever needed.
> Brett's extension isn't orthogonal. 

Ok, that's a possible reason for choosing a subclass over a module.  I 
hadn't seen the patch at the time of my original post, so I can't say if 
it is orthognal or not.  I shall ponder the issue ;)

> I want people to test. I want them to write all the unit, system,
> integration, and performance tests they possibly want. I want them to
> have the tools they need to do this, [...]

Absolute 100% agreement with the above.

> *nod* I think this is a fine alternative. I'd probably take it a step
> further and use it AND subclassing to make things both clearer and a
> bit easier.

I would suggest (as a rule of thumb) that the library writers provide 
modules and allow the end users to subclass and include the modules they 
want/need.

-- Jim Weirich


-- 
Posted via http://www.ruby-forum.com/.