Tels posted some of his Test::More experiences off-list. Some of them
are rather good so I'll post my reply on-list.
On Wed, Dec 19, 2001 at 10:42:55PM +0100, Tels wrote:
> * Use Test::Simple/More for new testfiles. It can help you. If Test::More
> scares you, use Test::Simple or only a subset of T::M.
> * Don't convert old tests needless, better spent the time adding tests.
> (But the conversation might take little time so try it if you have only a
> small testsuite).
If it makes you feel any better, I still have heaps of modules which I
haven't bothered to convert over to Test::More. I do it when I find
myself needing a Test::More feature and usually not before.
> For the Test-developers:
>
> * Test::More is already quite confusing (Especially since ok() is no longer
> what it used to be and you now must use is()!).
Actually, Test::More's ok() is just like Test's ok(). And its not.
Test.pm's ok() has at least three forms of operation.
ok( $foo eq $bar ); # like Test::More::ok()
ok( $foo, $bar ); # like Test::More::is()
ok( $foo, qr/bar/ ); # like Test::More::like()
and then there's some of the more out there functionality:
ok( $foo, $bar ); # like is( &$foo, $bar ); if $foo happens to
# be a code ref. I never understood why this
# magic was added.
ok( $foo, $bar ); # if $bar looks like a regex (ie. "/wibble/")
# it works as like(). Otherwise its is().
# Sucks if $bar == '/usr/local/'
So I preserved the first of the five (which just happened to
correspond to the way I wrote my custom ok() functions) because it is
the most generic of them all. You can write any test with it.
I also decided that Test::More users would have to learn five
different functions rather than learning one function with five
different modes of operation.
> Insted of spending time to add even more confusing functions that
> are used very little (if at all), shouldn't we do something more
> usefull?
>
> For instance, I know of a lot of CPAN modules without tests at all, and I
> talked to a few authors, and even if they decide to add tests (after my
> 'convincing' emails), it takes time, or never gets done, or the tests are
> to simple and too few. An even more confusing Test::More might scare them
> off even more.
Don't hand them Test::More, hand them Test::Simple. Or Test::Tutorial
which eases the user into the Test::More interface.
I *might* be convinced into adding is() to Test::Simple. I tend to
use that nearly as much as ok().
Test::More's interface is nearly complete. After diag() I don't think
I'm going to be adding any more functions. The rest will be either
Test::Builder methods or left to a 3rd party Test::Builder based
mix-in module (a la Test::Differences) to handle.
Of course, with Test::Builder you can make your own test library in
your own image and not have to listen to me anymore.
--
Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Some like elmers glue
but it needs reapplying.
I use super glue.
-- tlk
