----- Original Message ----
From: Michael G Schwern
On 7/15/06, Ovid wrote:
> > Just a thought:
> >
> > use Tests qw/
> > Exception
> > Differences
> > /;
> >
> > Have it import those modules and check for sub conflicts.
>
> This doesn't really buy you anything over:
>
> use Test::Exception;
> use Test::Differences;
First, it could simply be a case of me preferring a slightly cleaner interface
and this not being worth the trouble. I free confess that :) Also, even if
anyone thinks this is worthwhile, I have no intention of doing anything like
this until TAPx::Parser is at 0.10 (I have about half of the TODO list done:
http://perl-qa.yi.org/index.php/TAP::Parser).
Just because you don't mind typing those things over and over again doesn't
mean that others are of the same mindset. In fact, "test toolkit" might come
in handy there with something use "use Tests qw/:my_toolkit/;" which
automatically loads all of the common test modules I use. Maybe Damian's work
in this area might be handy.
> That already warns on import conflicts.
I wonder how many people, like me, are tired of watching a couple of hundred
tests scrolling past and thinking "did I just see some weird output? All the
tests pass", and then scrolling back through the TAP output to see if there
were any warnings, only to realize that the buffer of whatever they were using
didn't save enough lines (and yes, I know about Test::NoWarnings). Of course,
that would be another reason why colored test output would be very helpful.
> In fact you lose the ability to pass in any import routines.
>
> And where do you set the plan?
Good points.
use Tests
plan => 13,
qw/
Exception
Differences
/,
OtherTestModule => [ @import list ];
In practice I see very few test modules taking import lists and even fewer
tests using the import lists. The ugly syntax of that last line would be
rarely used. (Counter-examples welcome).
The "plan => 13" (and the corresponding "'no_plan2) could be problematic
because that would pretty much preclude using any hypothetical "Test::plan" or
"Test::no_plan" modules. I'm not overly worried about this.
In reality, most of the time we'd see stuff like this:
use Tests 'no_plan',
qw/
Exception
Differences
NoWarnings
/;
> > can_ok $proto, $method, $description;
> > isa_ok $instance, $class, $description;
>
> What problem are you trying to solve here?
>
> Is the slightly different interface from the rest of Test::More really
> a problem? They still don't line up with everything else as they're
> not of the form foo_ok $got, $expected, $description.
You've read the rest of this thread. You know the issue here. Many people
would prefer that $description always be the last thing you type and always be
something you can provide. Right now, sometimes you can provide that,
sometimes you can, and in the strange case of isa_ok(), you can *sort of*
provide it. Or when someone uses the rarely used SKIP: (I've read a lot of
test suites on the CPAN and very few people use it), then they get surprised
that $description is *not* the last thing they type and, unless they upgrade to
the version you provided yesterday (thanks for that, by the way), then they may
have no idea what's going on.
> The user will now have to remember "can_ok works
> like *that* except when I'm using Tests in which case it works like
> *that*". I would suggest instead providing new functions with
> different names than changing the way the old ones work.
Agreed.
> Finally, the interfaces are different for a reason. You often want to
> test a big list of methods with can_ok(). isa_ok() has a pretty
> narrow range of possible descriptions.
By providing separate functions which handle this, one can either use the
can_ok() and isa_ok() versions you've provided (and I suspect most will) or the
new versions provided with Tests.
> > skip $number, $description;
>
> $number is optional when 'no_plan' is on which would lead to things like:
>
> skip undef, "foo";
Hey, I think that's *great* syntax. It's very explicit what it means.
Or I could go with a variant of the Test.Simple syntax
(http://www.openjsan.org/doc/t/th/theory/Test/Simple/0.21/lib/Test/More.html):
if ( ! $have_some_feature ) {
SKIP($how_many, $description);
}
else {
ok( foo(), $test_description );
is( foo(42), 23, $another_test_description );
}
Cheers,
Ovid
