Michael G Schwern <[EMAIL PROTECTED]> writes:
> On Sat, Dec 15, 2001 at 04:09:19AM +0200, Jarkko Hietaniemi wrote:
>> I don't get all the different (well, only VMS and Cygwin, so far, but
>> I like to nip buds) MM_XXX test suites: won't they be testing pretty
>> much the same things?
>
> Yes, but with different values and, I'm sure, lots and lots of
> uniquely odd life support code.
>
> ExtUtils::MM_* is going to be very tricky to test even as individual
> modules. Trying to unify them at the same time will make life a lot
> more difficult, made exponentially harder by the fact that the
> behaviors of the various modules have drifted apart somewhat over the
> years.
>
> Once the tests are in place I'm going to start detangling common
> methods and functionality out into a top level ExtUtils::MM_Any to try
> and oust ExtUtils::MM_Unix from its position at the top of the
> hiearchy. When that's underway we can think about unifying the tests.
>
> About the only thing I could see unifying at this point in the MM
> tests is that they all respond to the same basic methods. Basicly a
> foreach loop around a shitload of can_ok() tests.
>
>
>> And frankly, the current MM_VMS.t is hardly
>> worth the bits it's printed on.
>
> Yeah, its still on the untested list because of that.
>
>
>> - What good is use_ok(), really? How is that better than... use?
>> Gives you a prettier output?
>
> Yep, it fails gracefully instead of simply exploding, and sometimes a
> module use failing doesn't mean the test can't continue. The old h2xs
> generated tests had a whole lot of confusing "# black magic" code to
> do exactly that, so I figured it was worthwhile.
>
>
>> - Ditto for isa_ok(). I find quite comical to do
>>
>> $foo = Foo->new;
>>
>> isa_ok($foo, 'Foo)';
>>
>> Have we suddenly stopped trusting the basic OO?
>
> We trust that Perl's method calls work, but we don't trust that the
> guy who wrote Foo got his constructors right. Possibilities include
> straight failure (ie. you get nothing), forgetting to bless() (its
> happened) or, if the constructor is some sort of adaptor/factory,
> returning an object which isn't a subclass of Foo.
Nothing wrong with an adaptor/factory returning something that isn't a
Foo, so long as it has the same interface. Actually, that can be one
of Perl's nicer aspects in that it becomes almost trivial to set up
mock objects (at work we use the PerlUnit harness and for some of the
more complicated classes we test it's been really handy to be able to
pass the test object (masquerading as, say, a message object) as an
argument without having to worry about inheritance issues (we cheat
and delegate sometimes...).
> Constructors fail often enough that I felt it worthwhile to write a
> test function for them.
>
> You could leave off the test entirely and just trust that you use $foo
> later on down in the test and it'll explode there, but its better to
> put the point of failure as close to where the bug is as possible.
> And you get no diagnostic information (see below).
Die early and die often eh?
>
> The equivalent code without isa_ok() would be:
>
> my $foo = Foo->new;
> ok( $foo->isa('Foo') );
>
> except should $foo be unblessed or undef that will explode. You have
> to start doing things like:
>
> my $foo = Foo->new;
> ok( defined $foo && $foo->isa('Foo') );
>
> which rapidly gets tiresome. It also provides you little information
> about what value $foo held that caused it to fail.
What's wrong with
ok ( eval { $foo->isa('Foo') } );
or even:
ok (eval { ref($foo) && $foo->isa('Foo') });
?
--
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?
