Re: Keeping SKIP Test Blocks Under Control

I noticed that your skip blocks all seem to be organized for fail-fast, that is, an initial test would bail all of the remaining tests.

Since ok() appears to return whether it was okay or not (not clearly documented; see source for Test::Builder::ok()), just last if not ok(...) ahead of any dependent tests. Now everything's at the same scope/level, instead of nested deeply.

There's also no harm in having more than one test script for a given module. I break up complicated testing into independent regions of functionality. Each rare situation where the tests can't be organized to use last if not ok(...) is a good candidate for starting a new script with its own sequence.

Lastly, I guess I don't see much value in the percentages and count of tests planned. It either failed to execute the test script, in which case perl will croak for you, or it succeeded in running the test script. It either failed a test, or all tests were ok(). Finding out that your module passes 93% seems of dubious or anecdotal value. So don't worry about messages to the effect of "script seems to have run 45 fewer than planned."

--
[ e d @ h a l l e y . c c ]

Comment on Re: Keeping SKIP Test Blocks Under Control Select or Download Code

Replies are listed 'Best First'.
Re: Re: Keeping SKIP Test Blocks Under Control by hardburn (Abbot) on Apr 12, 2004 at 17:46 UTC
just last if not ok(...) ahead of any dependent tests That breaks the test plan, which you are correct in saying that it doesn't have a lot of value, at least from a development point of view. However, it also has some value when your boss comes to your cube and asks what you're up to :) Even so, some of the other posts show that `skip` doesn't have to be nested at all, which works out the same as `last if not ok` but maintains the test's plan. There's also no harm in having more than one test script for a given module. In this case, it's a CGI::Application program and each page returned is strongly related to what was filled into the previous page's form. ---- `: () { :\|:& };:` Note: All code is untested, unless otherwise stated	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: Re: Keeping SKIP Test Blocks Under Control
by hardburn (Abbot) on Apr 12, 2004 at 17:46 UTC

just last if not ok(...) ahead of any dependent tests

That breaks the test plan, which you are correct in saying that it doesn't have a lot of value, at least from a development point of view. However, it also has some value when your boss comes to your cube and asks what you're up to :)

Even so, some of the other posts show that skip doesn't have to be nested at all, which works out the same as last if not ok but maintains the test's plan.

There's also no harm in having more than one test script for a given module.

In this case, it's a CGI::Application program and each page returned is strongly related to what was filled into the previous page's form.

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

[reply]
[d/l]
[select]