Test::Unit/PerlUnit refactoring on branch PDC_REFACTOR
[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
2. Use Error.pm as the basis for exception handling and try/catch/...
in place of eval.
3. Use Devel::Symdump in place of hand rolled symbol table manipulation.
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.
5. Started to port jUnit tests that make sense in the context of PerlUnit.
TODO: Need to get the procedural Test::Unit working. Or abandon it. However,
it does do some stuff that Test::More and friends don't (no plan testing
that actually produces a sensible 'test count')
Write more tests. (Patches welcome)
---snip---
I'm not entirely sure that all of this is necessary, but I think it
makes a good deal of sense to replace hand rolled stuff with packages
from CPAN where possible (admittedly Class::Inner got hand rolled by
me...), and it's *certainly* the case that Error.pm's
try {
...
}
catch Test::Unit::ExcpetionFailure with {
...
}
otherwise {
# soak up the error
}
finally {
...
}
is clearer than the eval stuff we've been doing.
I'm also toying with renaming a couple of classes --
Test::Unit::ExceptionFailure could almost certainly become
Test::Unit::Failure without and loss of clarity, but I'm also
seriously wondering about making the 'behind the scenes' classes (the
Assertion tree and the Exceptions) become:
T::U::Exception
T::U::Failure
T::U::Error
T::U::Assertion
T::U::Assertion::*
but this may just be excessive laziness on my part.
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() {...}
sub test_something : skip {...}
TestRunners can take (or not take) notice of this information. Time to
investigate Attribute::Handlers methinks. But first I'll get
Test::Unit working again.
Wanted:
More tests.
More examples.
Ports of the jUnit test suite (those parts that make sense).
Reports from Devel::Cover.
More/better documentation -- someone's just posted a tutorial in Word
format to one of the xp sites.
More reference sites...
--
Piers Cawley
www.iterative-software.com
Re: ANNOUNCE: Pod::Coverage 0.02 release
On Thu, Aug 30, 2001 at 10:30:24PM +0100, Richard Clamp wrote: > > Beside that, it seems not be able to find doc paragraphs for multiply > > functions like this: > > > > =head2 get_foo/get_blah/get_baz > > > > These functions get you an item back of the number and type you specified: > True, though I haven't personally seen those in the wild before. I've both seen them, and written them ;) Although I'll write them more when they're more conceptually the same: =head2 get_foo / set_foo Accessor and mutator for foo. Tony -- -- Tony Bowden | [EMAIL PROTECTED] | http://www.tmtm.com/ make me laugh make me cry enrage me don't try to disengage me --
Re: Test::Inline::Cookbook
On Fri, Aug 31, 2001 at 01:42:48PM -0400, darren chamberlain wrote:
> While beginning to use inline tests, Shane Landrum and I have
> started writing Test::Inline::Cookbook. It contains a few small
> snippets of code which we found useful while writing inline tests
> for a local module.
Hmmm, these aren't really specific to Test::Inline. They should go
into Test::Tutorial or better yet a general Test::HOWTO or
Test::Cookbook.
I'lll just s/Test::Inline/Test/ and this thing can become the start of
Test::Cookbook.
> NAME
> Test::Inline::Cookbook
>
> DESCRIPTION
> This file lists some ways you might want to use inline tests. Mostly,
> it's things you wouldn't know just from reading Test::Inline::Tutorial.
>
> Testing caller() scope
>
> So, let's say I have a routine that uses caller() to do something, and I
> need to test it. Here's my code:
>
> sub new {
> my $class = shift;
> my $name = shift || caller;
> my $value = shift || time;
>
> bless [ $name, [ $value ], ], $class;
> }
>
> sub name {
> my $self = shift;
> return $self->[0];
> }
>
> Because this routine uses caller() as a default, I need to be in another
> package to test that it's doing the right thing with caller. Here's a
> snippet of testing code that shifts to another package before testing.
>
> =begin testing
>
> my $x;
> {
> package Foo;
> $x = local::Config::Var->new;
> }
> is($x->name, "Foo", "new() with no arguments");
>
> =end testing
>
> Testing tied interfaces
>
> So, if I have a tied interface to my module, sometimes I need to test
> that the tying routines are doing the right things. Here's some code:
>
> sub TIESCALAR { shift->new(@_) }
> sub FETCH { shift->value(@_) }
> sub STORE { shift->set(@_) }
> sub DESTROY { }
>
> And here's how to test it:
>
> =begin testing
>
> tie $v, 'local::Config::Var', "Foo", 42;
>
> is(ref tied($v), 'local::Config::Var', "TIESCALAR works");
>
> $v = 43;
> is ((tied $v)->value, 43, "STORE works");
>
> $x = $v;
> ok(($x == (tied $v)->value), "FETCH works with numbers");
>
> $v = "string";
> ok(($v eq "string"), "FETCH works with strings");
>
> =end testing
>
> =cut
>
> AUTHORS
> Shane Landrum <[EMAIL PROTECTED]> Darren Chamberlain <[EMAIL PROTECTED]>
>
> SEE ALSO
> the Test::Inline::Tutorial manpage
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
...and I pull out the Magnum from under the desk where I keep it in case
someone laughs at a joke that's so dry it's got a built in
water-fountain, and blow the lot of them away as a community Service.
-- BOFH
