From: Ryan Davis <ryand-ruby@...>
Date: 2006-05-23T07:44:24+09:00
Subject: Re: Test::Unit Patch that allows test methods to be executed


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?

I guess where I'm getting at is this: Brett's modification is NOT a  
unit test extension. 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. As he said, it is a modification  
at a system or integration level. Test::Unit is a fine execution  
framework but TestCase in particular has some *cough*flaws*cough*  
design restrictions that make subclassing a bit of a PITA and as a  
result, TestCase gets used for everything. This is a shame IMO as  
I've pointed out elsewhere (http://blog.zenspider.com/archives/ 
2006/01/move_over_testu.html) but we have workarounds that are  
satisfactory.

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, but I also want those tools to  
not confuse them as to what type of tests they are writing and I  
think his patch is confusing.

> Rather, make the add-ins modules, then the user can mix-in whatever
> behavior they need.  For example ...
>
>    class MyTest < Test::Unit::TestCase
>      include FlexMock::TestCase
>      include Watir::TestCase
>
>      def test_using_both_watir_and_flexmock_extensions
>        ...
>      end
>    end
>
> Now, the flexmock one ties in by overriding teardown, so any user
> supplied setup/teardown methods should carefully invoke super (which
> they probably should do anyways).

*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.

--
_why: zenspider's most intense moments of solice are immediately  
following the slaughter [...]
_why: that topknot's the only thing keeping a lid on the righteous anger
bricolage: yeah, that and his flagrant obsession with dvorak