Re: [Perlunit-devel] Test::Unit/PerlUnit refactoring on branch PDC_REFACTOR

[Piers C. <pdc...@bo...>]

Adam Spiers <ad...@sp...> writes:

> Piers Cawley (pdc...@it...) wrote:
>> [This is posted to both the perl-qa and the perlunit-devel lists]
>> 
>> Okay, I've just checked in a new branch of the Test::Unit CVS with
>> some fairy serious changes in place. Here's the CVS log entry.
>> 
>> ---snip---
>> Beginnings of a major refactoring.
>> 
>> 1. Replace Test::Unit::InnerClass with Class::Inner
> 
> There are still references to Test::Unit::InnerClass; I guess you know
> about those.

Well, actually, I have the feeling that the code in my home directory
that went west didn't have any references to Test::Unit::InnerClass
(and maybe had some more tests as well...). Tell you what, lets just
fix what's in the repository...

>> 4. Also includes an attempt at an 'assert_equals' that does the right
>>    thing in most cases. Tries to make reasonable guesses about numeric or
>>    string comparison, and can make use of object based equality things.
> 
> <random_idea>
> 
> If we're going to be using Attribute::Handlers, it wouldn't be much
> more work to use Attribute::Util and do
> 
>  sub assert_equals : Alias(ok)
> 
> although IIRC some people don't want an ok() in the core framework,
> and it would introduce more module dependencies (not that we've
> shirked away from using other CPAN stuff so far).
> 
> If we did go down that road, Attribute::Protected is pretty sweet too.
> Maybe not enough gain for the extra hassle though?

I confess that I don't like the 'ok' approach to testing, but that's
purely a gut thing.

> </random_idea>
> 
>> I've also been thinking about test 'metadata', ie skiplists and the
>> like, and a little light went on:
>> 
>> sub test_something : todo {...}
>> sub test_something : skip_if(<condition>) {...}
>> sub test_something : skip {...}
>> 
>> TestRunners can take (or not take) notice of this information. Time to
>> investigate Attribute::Handlers methinks.
> 
> Ooh ooh nice idea!  I posted a patch implementing of skiplists (I
> called them filters) to this list on 5th March (subject "PATCH: adding
> state to the runner(s)"), but using Attribute::Handlers is a lovely
> way of tagging tests.  I can get cracking on this on Monday or
> Tuesday.  Shall I branch off your branch, or commit directly to it?

Oh, commit directly to it. I'm not going to be doing any working on it
this weekend (if I'm doing anything I'll be using it to write an
initial few tests for the refactoring browser I'm toying with...)

> 
>> Wanted:
>>
>> Reports from Devel::Cover.
> 
> Nice idea!  Hadn't seen that before.
> 
> Piers Cawley (pdc...@it...) wrote:
>> Right, I've made a whole load more changes on the PDC_REFACTOR branch.
>> Some nice stuff there, though I do say so myself. All the tests are
>> passing here (except for the try_examples.t, which has been failing
>> for a while anyway I believe).
> 
> Oops, saw that too late.  Can anyone say whether my proposed change to
> %guru_checked (see last post) is right or not?
> 
>> No work yet done on Skip/Todo stuff, though I've got a couple of ideas
>> in that direction. I'm quite keen on tests being able to throw
>> 'Test::Unit::Skip' exceptions, which the TestRunner will be able to
>> recognize.
> 
> Would that be as part of or in addition to the test attributes
> scheme?

I think it could well be in addition to. Very often a test can only
know that it should be skipped at runtime, so throwing a skip
exception makes more sense than the programmer deciding when he writes
the test that it should be skipped.

>> This doesn't really work with TODO type tests though...
> 
> Why's that, because TODO tests have to be run to make sure they don't
> succeed, or some other reason?

Because you know you're expecting the test to fail when you write it.
Deciding *at runtime* that the test is going to fail, well, it seems
to go against the grain somehow.

>> Check out Test::Unit::tests::AssertTest for what I think is the
>> beginnings of a neat approach to Results Matrix based testing.
> 
> Looks nice.

Actually, the more I look at that particular example, the more I find
myself thinking that it's over complex. Some kind of results matrix
thing is definitely a good idea, but I'm not sure that what I've got
is it.

>> I'm thinking of splitting Test::Unit::TestCase into
>> Test::Unit::TestCase::Simple, which doesn't do any reflection stuff at
>> all, just uses run_test, and Test::Unit::TestCase::Heavy, which will
>> provide list_tests and other reflective type stuff. Right now there's
>> a certain brainwarping effect when you find yourself dealing with a
>> class that seems to get used in two rather different ways.
> 
> Yeah.  I'm all for keeping classes simple too.

Hence my misgivings about the test matrix stuff. 

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?