On Sat, Apr 21, 2001 at 10:08:16AM +0100, Michael G Schwern wrote:
> >
> > I was thinking more along the lines of making the default name available
> > in something like $Pod::Tests::current_name and tweaking Test.pm and
> > others to look for it if a name isn't explicitly passed. That way the
> > Pod::Tests user has their choice of what Test* module to use.
>
> Eeeeww, that's the Really Intrusive way of doing it. Just because I
> happen to maintain most of the Test::* hierarchy doesn't mean I can
> get away with a hack like that.
Agreed that's Really Intrusive. But wrappers just don't cut it, there
are too many current and future test APIs to wrap. There needs to be
some common point to make the feature work, but all solutions I can
think of are intrusive. It'd be a very handy feature, though.
> The greater issue of how to allow people to use different Testing
> modules I'm going to punt at the moment. Maybe something like this...
>
> =for testing use My::Test
No need to punt, you are already at a decent solution in Pod::Tests, let
them choose.
> Test::More will be smart enough to handle it using the new "1..M at
> the end" Test::Harness feature.
Very cool, thanks. I hadn't seen the implementation detail on that
feature, it's just right.
> Yes, pod2tests would do "use Test::More noplan;" just as soon as I
> implement it.
I beg that pod2tests should not foist a testing API on the hapless
coder. It's way to easy to do
=for testing use Test::More noplan ;
if that's what's wanted. It's not worth saving a line of code if the
cost is constraining the user and having to add code to Pod::Tests to
handle the inevitable "but I really want to C<use Test::Better;>" cases.
Small, separate utilities that cooperate make sense to me here.
- Barrie
