On Sat, Apr 21, 2001 at 08:10:43AM +0100, Michael G Schwern wrote:
>
> So basically you want a default name for a block of tests? I can do
> that, basically by calling an ok() that's a wrapper around Test::ok()
> and will watch for a default name being set.
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.
> I'm going to switch over to Test::More as the default testing module
> next version anyway. This might break any existing embedded tests you
> have (since Test::More::ok() behaves differently than Test::ok()).
> Ummm... not sure how to ease that bit of pain.
I say don't mix Pod::Tests, a POD translator, with Test*, a collection
of testing utility APIs. Limits current and future flexibility.
> Wait... how are you doing this at all? Pod::Tests doesn't support
> multiple tests in a block yet.
Pod::Tests doesn't care, but pod2tests makes assumptions that I can't
figure out how to make smart enough (one test/POD paragraph). I don't
think that kind of utility can be made smart enough, which means the
programmer has to add something to tell how many tests there are. I
agree with you that the bloody computer should be smart enough to figure
out the number of tests, which is why I currently use my list of
closures testing style most places.
That's also why I think the simplest thing would be to run all the tests
and have the test suite emit "# testing complete\n" when exiting
normally, and have Test::Harness add up the number of tests.
Test::Harness should only whine if it hasn't seen a plan or the "#
testing complete\n" sign-off. Most module test suites do not need a
preannounced test count. I know, I know, submit a patch...
I'm using Pod::Tests and thinking that it should never try to be too
clever in counting up number of tests. The single most useful feature
discussed on this whole list is plan => noplan, and I'd prefer to have
that be the default.
Ok, now that that's all off my chest, here's how I'm using Pod::Tests in
a module:
package WV::WebUtil ;
## <snip>use strict, various POD, etc</snip>
use SelfTest ;
=for testing
use strict ;
use Test ;
use WV::WebUtil ;
plan tests => 1 ;
## ... and then on to the module code and test POD.
I'll switch to whatever cool stuff you write that supports noplan :-)
when it comes out. Or tot up the number of tests and change the "1".
- Barrie
