in reply to too much testing?

Is the "missing" subroutine an indication that nobody else bothers to test for such conditions? Or just an oversight by the module author?

I think the best answer here is "design choice". Test::More is meant to be a core set of tests that handle the day-to-day basic Stuff You Gotta Do. So you can do the basics: this did what I expected, or something different; this is the same as that, as I expected, or it's different, as I expected. The "deeply" versions just amp up that basic test a little: like the thing I expected, or not.

Test::Exception, Test::LongString, Test::Tester, Test::WWW::Simple, and on and on, just add a little more specific testing power in specific areas.

Another possibility is to put Test::Exception in t/lib and distribute it with your code. That way you get the win of getting the test you want without requiring the user to install it.

Yet another is to check for whether Test::Exception is available on the machiine where the module's being installed, and skip the tests if it isn't. This is the way I generally prefer to handle such things; I use this for POD tests, which are useful to me, but maybe not so much to the person installing this module later.

Replies are listed 'Best First'.
Re^2: too much testing?
by ForgotPasswordAgain (Vicar) on Oct 03, 2005 at 09:30 UTC

    If that was a design choice, why was it called Test::More? I'm thinking of Matrix Reloaded, when Agent Smith demands more agents join the fight with Neo. MORE!

    I also don't think it's consistent with the DESCRIPTION in Test::More's perldoc:

    The purpose of this module is to provide a wide range of testing utilities. Various ways to say "ok" with better diagnostics, facilities to skip tests, test future features and compare complicated data structures. While you can do almost anything with a simple "ok()" function, it doesn't provide good diagnostic output.

    And incidentally, I've also wondered why there wasn't a not_ok function.

[reply]
      If that was a design choice, why was it called Test::More

      Because it tests more than Test::Simple. It's not Test::Everything :-)

      Schwern (quite rightly in my opinion) has kept Test::More to a minimal set of useful stuff.

      And incidentally, I've also wondered why there wasn't a not_ok function.

      Probably because providing one wouldn't really give you any additional useful information over doing something like:

      ok( not $expected_to_be_false  );

      [download]
[reply]
[d/l]
Re^2: too much testing?
by geektron (Curate) on Oct 03, 2005 at 08:12 UTC
    I think the best answer here is "design choice".
    i'm in agreement here, after reading some replies and thinking about it more.

    i'm not worried about packaging any of the Test::* modules with the "distribution", because there won't be a distribution. the code i'm writing now is application-specific.

    for added testing, I've already installed Test::Pod::Coverage and Test::Exception. i'm trying (and some days i wonder why) to get this code to look as much like something that could be publically distributed, even though i can't imagine why this app-specfic code would make it off the server. it's a learning experience ... writing more POD, making sure that the modules/classes have better-than-adequate documentation and tests ... so that the the next developer that comes along (even if it is me 6 months from now) can make sense out of the code and NOT have to learn by reverse engineering it ...

[reply]

In Section Meditations