Re: [ANNOUNCE] Test::Warn::None 0.02
On Wednesday 02 July 2003 00:25, Adrian Howard wrote:
> On Monday, June 30, 2003, at 02:07 pm, Fergal Daly wrote:
> The footer doesn't indicates that the correct number of tests ran
> (that's the plan's job), it just shows that a test script completed
> without error.
I think that would be useful.
> So a noplan test might look like
>
>ok 1
>ok 2
>1..2
># fin
>
> a planned test with an extension might look like
>
>1..2
>ok 1
>ok 2
>3..3
>ok 3
># fin
but what if your script outputs
1..2
ok 1
ok 2
# fin
there is no way to know that there's an extension missing. It might sound
unlikely that this would happen but take the Test::NoWarnings module and say
it works by extending the plan at the end and say for some reason it's buggy
or even that you forgot the use it. There'd be no way to know that the END
block didn't run.
There's a good chance that when writing scripts people will naturally bundle
the plan extension and the tests together as a unit, possibly even in a
subroutine which makes it even easier for the whole things to be silently
skipped.
The purpose of the plan is to declare in advance how many tests will run, so
that if an error in your script or some exceptional circumstances cut the
test short, you will find out. The reason plans are effective is because they
are declared very early, before anything has a chance to go wrong. If the
plan is changeable then when the script finishes you have know way of knowing
if the plan was changed the correct number of times.
The current situation is bullet proof, if a test is missed the plan will be
wrong, end of story The only way to make extensions just as bullet proof is
to predeclare your extensions too, so your plan becomes x tests and y
extensions.
> To be honest, I'm not sure that having a global plan at the test script
> level gives you that much benefit.
>
> I like planned tests, but a manually maintained global plan is a
> maintainence nightmare if you have a large number of tests, or if the
> number of tests is runtime dependant.
Absolutely, that's the big problem with plans they are too difficult. That's
the problem arbitrarily nested sub blocks (each with their own plan) solve. A
global plan is hard to maintain because the plan is far away from the tests.
By using blocks, each with their own plan, things are much easier, if you add
a test to a block, you just need to update the plan for the block, that's it,
no changes required anywhere else.
It allows the testing equivalent of structured programming, local changes do
not require global mainteance. I rarely use plans at the moment because I
write a lot of scripts like this
foreach my $thing (@things)
{
do_some_comlicated_test($thing);
}
run_some_other_test();
sub do_some_complicated_test
{
is_this($thing);
is_that($thing);
is_the_other($thing);
}
so the plan is number of elements in @things X number of tests in the
subroutine + other tests. A royal pain to maintain. If I could do this
use Test::More tests => 3;
{
block(tests => 20);
foreach my $thing (@things)
{
do_some_comlicated_test($thing);
}
}
a_test(@things);
another_test(@things);
sub do_some_complicated_test
{
block(tests => 3);
is_this($thing);
is_that($thing);
is_the_other($thing);
}
that makes my plan a doddle to maintain.
> I've not noticed any problems now that I use Test::Class for most of
> my test code. I still plan the number of tests executed - I just do it
> at the method-level rather than the test-script level.
I'm not familiar with it although it looks nice. I'm guessing that Test::Class
calculates your global plan for you? One advantage to the block approach over
extensions or autoplanners is that you will know exactly which block ran too
many or too few tests, whereas with a global plan, you just know that
somewhere something went wrong, maybe you go hunting for it, maybe you "fix"
the plan.
> That would work, but you face the problem of having an evil
> internal-error causing your script to exit early without getting any
> output from earlier tests. You also lose user feedback for long test
> sequences (you only find out that test 2 failed after all 276000 test
> run).
Absolutely, that idea was just thrown out for discussion. There's another one
percolating but it's not quite there yet, it goes something like
plan 1..3
plan .1 1..5
ok .1.1
ok .1.2
ok .1.3
plan .1.4 1..2
ok .1.4.1
ok .1.4.2
ok .1.5
ok .2
ok .3
1..8
Which is compatible with the current TH protocol (which is why all the test
numbers are preceeded by .s) but a newer TH could figure it out. It doesn't
depend on indentation, so tests can be carried out in any old order, allowing
the cross-cutting AOP tests you mentioned and it also caters for wacky
threaded scripts too.
> Being able to extend the plan seems a simpler solution to
Re: [ANNOUNCE] Test::Warn::None 0.02
On Monday, June 30, 2003, at 02:07 pm, Fergal Daly wrote: On Wednesday 25 June 2003 20:15, Adrian Howard wrote: Add an explicit "test script finished" footer? But how does the footer-adder know that the correct number of tests ran. You would need to declare a plan to run x additional extensions at which point you're doing sub-plans. The footer doesn't indicates that the correct number of tests ran (that's the plan's job), it just shows that a test script completed without error. So a noplan test might look like ok 1 ok 2 1..2 # fin a planned test with an extension might look like 1..2 ok 1 ok 2 3..3 ok 3 # fin and a test with a failed extension might look like 1..2 ok 1 ok 2 # some ghastly error that caused an early exit and no error code on exit and Test::Harness would pick up the lack of a "# fin" as indicating a premature exit. Most early exits would be caught via the bogus exit value anyway. Having an explicit "script complete" footer would only catch a few odd cases. Of course if we carry on much longer we're going to end up with T::H and T::B having to do nasty version checks to make sure they're talking the same protocol :-) I suppose I'm thinking of things from the I messed up my test script point of view rather than my test script died unexpectedly. Exit codes should catch the died unexpectedly stuff. A correct plan is good for catching the programmer errors but is a pain to maintain. To be honest, I'm not sure that having a global plan at the test script level gives you that much benefit. I like planned tests, but a manually maintained global plan is a maintainence nightmare if you have a large number of tests, or if the number of tests is runtime dependant. I've not noticed any problems now that I use Test::Class for most of my test code. I still plan the number of tests executed - I just do it at the method-level rather than the test-script level. That's why I liked the previous suggestions about being able to extend plans. It seemed a nice simple way to get the security of being able to have micro-plans without having to worry about the global plan count. (not that we couldn't do it your way too). I have some vague thoughts that there are some potentially cute things that you could do with extended plans that would be hard to do with sub-blocks/plans (e.g. any sort of test that cross-cuts several test scripts in an AOPish sort of way - checking that test data has returned to a state of grace for example). I guess that can be solved by controlling the timing of the output. I don't think there's a need for the results of test 1 to be printed before carrying out test 2, except maybe when the tests are being run by the developer. That would work, but you face the problem of having an evil internal-error causing your script to exit early without getting any output from earlier tests. You also lose user feedback for long test sequences (you only find out that test 2 failed after all 276000 test run). Being able to extend the plan seems a simpler solution to me. Adrian
Re: [ANNOUNCE] Test::Warn::None 0.02
On Wednesday 25 June 2003 20:15, Adrian Howard wrote: > Add an explicit "test script finished" footer? But how does the footer-adder know that the correct number of tests ran. You would need to declare a plan to run x additional extensions at which point you're doing sub-plans. I suppose I'm thinking of things from the I messed up my test script point of view rather than my test script died unexpectedly. Exit codes should catch the died unexpectedly stuff. A correct plan is good for catching the programmer errors but is a pain to maintain. > I have some vague thoughts that there are some potentially cute things > that you could do with extended plans that would be hard to do with > sub-blocks/plans (e.g. any sort of test that cross-cuts several test > scripts in an AOPish sort of way - checking that test data has returned > to a state of grace for example). I guess that can be solved by controlling the timing of the output. I don't think there's a need for the results of test 1 to be printed before carrying out test 2, except maybe when the tests are being run by the developer. The patch I submitted almost allows that to work. Each block gets a Test::Builder object and whenever a block is finalised, it finalises all of it's sub blocks, so you could delay output until finalisation time. So, imagine that Test::Builder objects don't output anything until they are finalised, they just collect results quietly. You create an AOP block at the top level (ie a sub-block of the root Test::Builder). Then you do all your AOP tests using this Test::Builder::Block object. At the end, when all other tests are finished and output, your AOP test block will dump out it's results. F
Re: Renaming modules (was Re: [ANNOUNCE] Test::Warn::None 0.02)
On Sat, Jun 28, 2003 at 10:13:06PM +0100, Fergal Daly wrote:
> On Saturday 28 June 2003 02:51, Michael G Schwern wrote:
> > When I merged Test::Simple with Test::More I left a Test-More tarball lying
> > around containing a Makefile.PL which simply died saying "download
> > Test-Simple instead".
>
> That's OK for a merge (or you could have an empty archive with a dependency on
> Test::Simple so CPAN.pm can be happy.)
>
> I don't think dieing is a good idea for a rename or a deprecation. It's
> probably a good thing to die when a developer gets your module but if a user
> gets it to satisfy a dependency then it shouldn't fail. Is there a way to
> know if Makefile.PL is being run by CPAN.pm?
There's no need, CPAN.pm won't pick up the old named module. All it
contains is a Makefile.PL and a MANIFEST. Perhaps a README. There is no
.pm files for the CPAN indexer to pick up on. search.cpan.org shouldn't
even pick up on it. The only way a user could find that tarball is to
manually download it from CPAN. Its just a hollow dummy. There's no other
reason someone would download the dummy.
To make it clear, what you would do is release a Test-Warn-None-0.05.tar.gz
which contained a Makefile.PL which died with a message about having been
renamed to Test::NoWarnings and to download Test-NoWarnings instead. That's
for the folks still downloading modules by hand.
For those using the CPAN shell or modules having dependencies on the old
name (Test::Warn::None), Test-NoWarnings could contain all the normal stuff
plus a Test::Warn::None which is a thin wrapper around Test::NoWarnings so
backwards compat is maintained. It also means that CPAN will index this
tarball as having Test::Warn::None in it so when the CPAN shell tries to
install Test::Warn::None it downloads Test-NoWarnings.
Optionally, you could put a warning about using Test::NoWarnings when
Test::Warn::None starts up.
The Test::Warn::None wrapper might look like this:
package Test::Warn::None;
use Test::NoWarnings;
@ISA = qw(Test::NoWarnings);
sub import {
shift;
@_ = ('Test::NoWarnings', @_);
goto Test::NoWarnings->can('import');
}
1;
Simply fooling Test::NoWarnings->import into thinking it was called.
--
It's Crack Cocaine time!
Re: Renaming modules (was Re: [ANNOUNCE] Test::Warn::None 0.02)
On Sat, Jun 28, 2003 at 10:13:06PM +0100, Fergal Daly wrote: > Is there a way to > know if Makefile.PL is being run by CPAN.pm? Not as far as I know, but Jos tells me that there should be some way in the next version of CPANPLUS. My personal itch that this would scratch is to be able to specify prerequisites if they can be easily satisfied, and just to output a message if the installation is manual and the prerequisites are not essential. (Yes, I know that doesn't make sense.) -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Renaming modules (was Re: [ANNOUNCE] Test::Warn::None 0.02)
On Saturday 28 June 2003 02:51, Michael G Schwern wrote: > When I merged Test::Simple with Test::More I left a Test-More tarball lying > around containing a Makefile.PL which simply died saying "download > Test-Simple instead". That's OK for a merge (or you could have an empty archive with a dependency on Test::Simple so CPAN.pm can be happy.) I don't think dieing is a good idea for a rename or a deprecation. It's probably a good thing to die when a developer gets your module but if a user gets it to satisfy a dependency then it shouldn't fail. Is there a way to know if Makefile.PL is being run by CPAN.pm? That way you could release My-Module-0.40_please-use-My-Better-Module-instead.tgz. This would have docs telling developers to use My::Better::Module instead and it would die for perl Makefile.PL but compile fine with CPAN.pm or perl Makefile.PL --i_really_want_this It would be good to be able to signal to the CPAN indexer that a module has been superceeded by another. F
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tue, Jun 24, 2003 at 08:39:39PM +0100, Fergal Daly wrote: > Test::NoWarnings sounds good to me. What is the correct etiquette for > abandoning a namespace? Just delete the files with PAUSE or should I leave a > pointer behind? Not too important with this module but I'm just curious, When I merged Test::Simple with Test::More I left a Test-More tarball lying around containing a Makefile.PL which simply died saying "download Test-Simple instead". -- Is there an airport nearby or is that just my tae-kwon-do taking off?
Re: [ANNOUNCE] Test::Warn::None 0.02
On Wed, Jun 25, 2003 at 07:09:26PM +0100, Fergal Daly wrote: > I just thought of a big problem with plan extensions. If the script silently > eat's itself just before you extend the plan, then you don't know that > anything went wrong. It would have to also exit normally. That is rare. -- Is there an airport nearby or is that just my tae-kwon-do taking off?
Re: [ANNOUNCE] Test::Warn::None 0.02
Hiya, On Wednesday, June 25, 2003, at 07:09 pm, Fergal Daly wrote: On Wednesday 25 June 2003 17:49, Adrian Howard wrote: The thread from the start of May about having optional / extendable plans supported by Test::Harness would seem to be a good match for this feature. http://archive.develooper.com/[EMAIL PROTECTED]/msg01883.html (Plan is YAGNI) [snip] I just thought of a big problem with plan extensions. If the script silently eat's itself just before you extend the plan, then you don't know that anything went wrong. Add an explicit "test script finished" footer? The problem is that counting the number of tests in a script is usually somewhere between awkward and impossible. Extendable plans make the symptoms go away but they also make some of the benefits of plans go away too. Subblocks and subplans accomplish the same thing without any loss of plan-strictness. [snip] I like the idea of sub-blocks/plans too (I still aim to tidy up Test::Block when the free time fairy next visits :) but I think the problems with extending plans can be overcome. I have some vague thoughts that there are some potentially cute things that you could do with extended plans that would be hard to do with sub-blocks/plans (e.g. any sort of test that cross-cuts several test scripts in an AOPish sort of way - checking that test data has returned to a state of grace for example). Anyway, food for thought. Adrian
Re: [ANNOUNCE] Test::Warn::None 0.02
On Wednesday 25 June 2003 17:49, Adrian Howard wrote: > The thread from the start of May about having optional / extendable > plans supported by Test::Harness would seem to be a good match for this > feature. > > http://archive.develooper.com/[EMAIL PROTECTED]/msg01883.html (Plan is > YAGNI) > > Test::Warn::None could then just extend the plan in the END block with > no worries about mucking up existing plans. I forgot about that stuff. I just thought of a big problem with plan extensions. If the script silently eat's itself just before you extend the plan, then you don't know that anything went wrong. The problem is that counting the number of tests in a script is usually somewhere between awkward and impossible. Extendable plans make the symptoms go away but they also make some of the benefits of plans go away too. Subblocks and subplans accomplish the same thing without any loss of plan-strictness. Of course that still doesn't solve the problem of END block plans but at least now all the tests in an END block can be grouped together with their own subplan and you only need to add 1 to the overall plan. It also makes skip and todo blocks very easy too, as long as all the tests to be skipped are in a sub-block then it's as if you're just skipping 1 test. > (Nice module BTW - and my vote is for Test::NoWarnings as the name :-) Thanks. I did decide to Test::NoWarnings but then I thought again. I think I'm going to roll my own version of Test::Warn (maybe Test::Warnings). Three main reasons: - Test::Warn has a lot of dependencies - Array::Compare, Test::Exception, Sub::Uplevel, Tree::DAG_Node (!), File::Spec - I want to capture the warnings in more detail - I have no job! I may as well be gainfully unemployed. When it's done, maybe I can persuade Janek Schleicher to inegrate it into Test::Warn, F
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tuesday, June 24, 2003, at 07:53 pm, Michael G Schwern wrote: On Tue, Jun 24, 2003 at 12:07:19PM +0100, Fergal Daly wrote: Consider the following. use Test::More; use Test::Warn::None; plan tests => 42; To make this work I'd have to overhaul the internal Test::Builder planning system to allow Test::Warn::None to say "I'm going to add an extra test, please remember this fact". I can be convinced its worth it. It seems like a good idea to me. Are there any other modules that would use it? Potentially, but I can't think of anything at the moment. The thread from the start of May about having optional / extendable plans supported by Test::Harness would seem to be a good match for this feature. http://archive.develooper.com/[EMAIL PROTECTED]/msg01883.html (Plan is YAGNI) Test::Warn::None could then just extend the plan in the END block with no worries about mucking up existing plans. (Nice module BTW - and my vote is for Test::NoWarnings as the name :-) Adrian
Re: [ANNOUNCE] Test::Warn::None 0.02
Michael G Schwern wrote in perl.qa : > On Tue, Jun 24, 2003 at 02:04:25PM -0500, Andy Lester wrote: >> All this "make sure no warnings fired" is good thinking. But why not >> roll it into Test::Harness, and make it switch selectable? It's >> really T::H that we want keeping an eye on this, right? > > No, its definately a test feature. Much easier to set up (no MakeMaker > muckery), finer granularity (can be done on a per test file basis rather > than a whole suite) and can distinguish between warnings and diagnostic > output (ie. warn() vs diag() vs print STDERR). > > Besides, Test::Harness can't portably trap STDERR. If you can figure out > a way to do it that would solve lots of problems. > > If you want to do it to a whole test suite, PERL5OPT=-MTest::Warn::None comes > to mind. Provided that all test scripts are written with a Test::Warn::None-compatible plan(). -- Don't use color combinations that cause problems for people with color blindness in its various forms. -- W3C, HTML 4.01 Specification, 6.5.1
Re: [ANNOUNCE] Test::Warn::None 0.02
Michael G Schwern wrote in perl.qa : > On Tue, Jun 24, 2003 at 01:36:52PM +0200, Rafael Garcia-Suarez wrote: >> BTW, what about modules that define their own category of warnings >> (via warnings::register) ? It'd be useful to have a module to ease >> testing for warnings presence/absence on certain conditions. > > There's Test::Warn, but I don't think it does anything special with > registered warning classes. It doesn't support them for now, according to the docs. >> (Avoiding to span perl interpreters at each test would be a bonus.) > > I don't quite understsand what "spanning perl interpreters" means. qx// (like lib/warnings.t in the perl core) -- Is it any wonder the world's gone insane, with information come to be the only real medium of exchange ? -- Thomas Pynchon, Gravity's Rainbow
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tue, Jun 24, 2003 at 02:04:25PM -0500, Andy Lester wrote: > All this "make sure no warnings fired" is good thinking. But why not > roll it into Test::Harness, and make it switch selectable? It's > really T::H that we want keeping an eye on this, right? No, its definately a test feature. Much easier to set up (no MakeMaker muckery), finer granularity (can be done on a per test file basis rather than a whole suite) and can distinguish between warnings and diagnostic output (ie. warn() vs diag() vs print STDERR). Besides, Test::Harness can't portably trap STDERR. If you can figure out a way to do it that would solve lots of problems. If you want to do it to a whole test suite, PERL5OPT=-MTest::Warn::None comes to mind. -- "Congratulations, you're a thieving bastard... Now give me back my pants." "That's MISTER Pants!" -- Ian's Adventures In Morrowind http://www.machall.com/morrowind/page3.html
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tue, Jun 24, 2003 at 01:36:52PM +0200, Rafael Garcia-Suarez wrote: > BTW, what about modules that define their own category of warnings > (via warnings::register) ? It'd be useful to have a module to ease > testing for warnings presence/absence on certain conditions. There's Test::Warn, but I don't think it does anything special with registered warning classes. > (Avoiding to span perl interpreters at each test would be a bonus.) I don't quite understsand what "spanning perl interpreters" means. -- It's Yellowing Laudanum time!
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tue, Jun 24, 2003 at 12:07:19PM +0100, Fergal Daly wrote: > > Consider the following. > > > > use Test::More; > > use Test::Warn::None; > > plan tests => 42; > > > > To make this work I'd have to overhaul the internal Test::Builder planning > > system to allow Test::Warn::None to say "I'm going to add an extra test, > > please remember this fact". I can be convinced its worth it. > > It seems like a good idea to me. Are there any other modules that would use > it? Potentially, but I can't think of anything at the moment. -- Loon.
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tue, Jun 24, 2003 at 12:37:36PM +0100, Fergal Daly wrote: > Also how about calling it Test::Warn::Auto? I'm not particularly happy with > None, Test::Warn::Auto doesn't say anything about its main purpose: to ensure that you have no warnings. Instead it documents an implementation detail, that the check for no warnings is automatic. I like Test::Warn::None or some variation on it. Or even Test::NoWarnings. Doesn't have to sit in the Test::Warn namespace. -- You're the sickest teenager I've ever set my wallet on.
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tuesday 24 June 2003 20:31, Michael G Schwern wrote: > If you want to do it to a whole test suite, PERL5OPT=-MTest::Warn::None comes > to mind. That's cool, I never saw that before. It's also a pretty convincing argument for an "I'm going to add an extra test" method in Test::Builder, F
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tuesday 24 June 2003 19:55, Michael G Schwern wrote: > I like Test::Warn::None or some variation on it. Or even Test::NoWarnings. > Doesn't have to sit in the Test::Warn namespace. Test::NoWarnings sounds good to me. What is the correct etiquette for abandoning a namespace? Just delete the files with PAUSE or should I leave a pointer behind? Not too important with this module but I'm just curious, F
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tuesday 24 June 2003 20:04, Andy Lester wrote: > All this "make sure no warnings fired" is good thinking. But why not > roll it into Test::Harness, and make it switch selectable? It's > really T::H that we want keeping an eye on this, right? Possibly... ...except how does Test::Harness know the difference between a diagnostic and and a warning that began with "#"? Or indeed the difference between something printed on STDOUT and something that came out via warn or the 'warnings' modules? F
Re: [ANNOUNCE] Test::Warn::None 0.02
All this "make sure no warnings fired" is good thinking. But why not roll it into Test::Harness, and make it switch selectable? It's really T::H that we want keeping an eye on this, right? xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tuesday 24 June 2003 19:56, Michael G Schwern wrote: > I don't quite understsand what "spanning perl interpreters" means. Neither did I until just now. I think it's the fact that forks will cause the END to run multiple times. It would be nice if Test::Builder gave a method to give us access to $Original_Pid. I suppose I can track it myself though, F
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tuesday 24 June 2003 12:36, Rafael Garcia-Suarez wrote: > +1 for ::Auto. > > BTW, what about modules that define their own category of warnings > (via warnings::register) ? It'd be useful to have a module to ease > testing for warnings presence/absence on certain conditions. > (Avoiding to span perl interpreters at each test would be a bonus.) I think Test::Warn is what you want although I haven't really explored it, F
Re: [ANNOUNCE] Test::Warn::None 0.02
Fergal Daly wrote: > > Also how about calling it Test::Warn::Auto? I'm not particularly happy with > None, +1 for ::Auto. BTW, what about modules that define their own category of warnings (via warnings::register) ? It'd be useful to have a module to ease testing for warnings presence/absence on certain conditions. (Avoiding to span perl interpreters at each test would be a bonus.)
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tuesday 24 June 2003 12:04, Tels wrote: > > It IS obsolete. I DOES call it from an END block ;-) > > Uh - *hides in a corner for the rest of the day* It happens to the best of us. I've updated the docs to make this more clear. Also how about calling it Test::Warn::Auto? I'm not particularly happy with None, F
Re: [ANNOUNCE] Test::Warn::None 0.02
-BEGIN PGP SIGNED MESSAGE- Moin, On 24-Jun-03 Fergal Daly carved into stone: > On Tuesday 24 June 2003 11:37, Tels wrote: >> Actually, I can see that Test::Warn::None could make the no_warnings() >> line >> obsolete by calling this automatically in an END block. So: > > It IS obsolete. I DOES call it from an END block ;-) Uh - *hides in a corner for the rest of the day* Cheers, Tels - -- Signed on Tue Jun 24 13:04:19 2003 with http://bloodgate.com/tels.asc perl -MDev::Bollocks -le'print Dev::Bollocks->rand()' conveniently industrialize bleeding-edge technologies http://www.notcpa.org/ You have the freedom to run any code. Yet. http://bloodgate.com/perl My current Perl projects -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl. iQEVAwUBPvgwM3cLPEOTuEwVAQGMbgf7BHTxc7QXaLJYcSCWRtjtaxPWKH081Kmn +fqa2VavcIWzN5taXXsn0I2113eAfvMCxDu6UNtNv9UX6mXePUgQFO4+zI3Q4l4P eO6JOLXzOUJUpDhkZlXSepHaTnnYIC5bhBBaRsGlUvjb4iqgONUEm82f1milNWVQ mVle2ykJxZSMZ2wX24XNWib/do0sNwuu1sxdqp2ksYAvrMkhzgpz4NhWfaqG1PKk RXkKr9G/6gxQPEi61QpcACoQQkNgS1YzSV7+ispmBq2XBRRceLoQU80VuLHYfdf2 LGzeGAXMXUuPPnCMhErFFJzL7Sv/87uOMJRAdfovP5Nf1uDVAFH9Og== =3c/i -END PGP SIGNATURE-
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tuesday 24 June 2003 11:22, Michael G Schwern wrote: > > >> use Test::More::None; > > Typo? Yeso. > > > > Can't nowarings() call Test::More::plan_add(1) or something like this? > > > > Consider the following. > > use Test::More; > use Test::Warn::None; > plan tests => 42; > > To make this work I'd have to overhaul the internal Test::Builder planning > system to allow Test::Warn::None to say "I'm going to add an extra test, > please remember this fact". I can be convinced its worth it. It seems like a good idea to me. Are there any other modules that would use it? F
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tuesday 24 June 2003 11:37, Tels wrote: > Actually, I can see that Test::Warn::None could make the no_warnings() line > obsolete by calling this automatically in an END block. So: It IS obsolete. I DOES call it from an END block ;-) F
Re: [ANNOUNCE] Test::Warn::None 0.02
-BEGIN PGP SIGNED MESSAGE-
Moin,
On 24-Jun-03 Michael G Schwern carved into stone:
> On Tue, Jun 24, 2003 at 10:59:43AM +0200, Tels wrote:
>> > On Mon, Jun 23, 2003 at 05:49:06PM +0100, Fergal Daly wrote:
>> > Good idea. Too bad about the plan calculation hackery necesssary. :(
>>
>>
>> Can't nowarings() call Test::More::plan_add(1) or something like this?
>>
>
> Consider the following.
>
> use Test::More;
> use Test::Warn::None;
> plan tests => 42;
>
> To make this work I'd have to overhaul the internal Test::Builder
> planning system to allow Test::Warn::None to say "I'm going to add an
> extra test, please remember this fact". I can be convinced its worth it.
IIUC, we have:
# manual way
use Test::More;
use Test::Warn::None;
BEGIN
{
plan => tests 1 + 1; # one extra for no warnings
}
ok ()
no_warnings();
and:
# automatic way (not yet)
use Test::More;
use Test::Warn::None;
BEGIN
{
plan tests => 1;
}
ok (...);
no_warnings();
Neither the manual way nor the automatic way can be "fooled", except that
you remove the "use Test::Warn::None" line. (Either way would
screem if the no_warnings() would no longer be called). So as a vivid plan
user, I would be for the way that requires less typing.
Actually, I can see that Test::Warn::None could make the no_warnings() line
obsolete by calling this automatically in an END block. So:
# fully automatic way, washes your socks and makes coffee
use Test::More;
use Test::Warn::None;
BEGIN { plan tests => 1; }
ok (...);
(use Test::Warn::None qw/auto/ or something might also work if you
don't want to change the interface)
As to the "overhaul": wouldn't one extra variable with the "extra tests do
plan for" be enough? Sorry, I probably assume to much simplicity behind
the scenes :)
I would like this, because I plan to use Test::Warn on more than one 20+
test-scripts testsuite, and I could even see how this could be added to the
core which has even more scripts :)
Best wishes,
Te"feels bad for just wanting more features without any contribution"ls
- --
Signed on Tue Jun 24 12:36:15 2003 with http://bloodgate.com/tels.asc
perl -MDev::Bollocks -le'print Dev::Bollocks->rand()'
continuously deploy efficient functionalities
http://www.notcpa.org/ You have the freedom to run any code. Yet.
http://bloodgate.com/perl My current Perl projects
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.
iQEVAwUBPvgppncLPEOTuEwVAQF0oQf+OfU+k7Z3Rv02khEObEo+W/LMQgNpkmPS
TpigCsLOy8Mnk1y4wRY+iGqKyydXvAI8MtmFnYl+90L4xi3R/uifDz5rwhoxoXJk
e8Xx8ZXU9koijK4hCHZgQ2YBE9rt8qmfSo/elEbLBxT929NNyZeaKhw9tpHbAnNq
NKTIYAmv0nfJMhLdJofXXOgHvUmbkzuE4L5B5hCoC1Ej1hLdTcTc8hzJoOjKX41y
3ST8rBAZi/bzgeG4EnSS2maDiRdt5hvNd6g29XDoo9XujjplQjYEuuMi2nzanxj9
MuI3mXg8qE+pHJjqO/WSbnMqQl9LDxkpYkbIlDlHHMUyQHP8okavzQ==
=MU0t
-END PGP SIGNATURE-
Re: [ANNOUNCE] Test::Warn::None 0.02
On Tue, Jun 24, 2003 at 10:59:43AM +0200, Tels wrote: > > On Mon, Jun 23, 2003 at 05:49:06PM +0100, Fergal Daly wrote: > >> I'm looking for comment or suggestions about this new module. It's > >> independent of and complementary to Test::Warn. It tests that your test > >> script didn't emit any warnings. Just add > >> > >> use Test::More::None; Typo? > >> to the top your test script, update your plan (if you've got one) and > >> that's > >> it. You'll get an extra test, executed after your script ends checking > >> whether there were any warnings. If there were you'll get a full run > >> down of > >> them including a stack trace. > > > > Good idea. Too bad about the plan calculation hackery necesssary. :( > > > Can't nowarings() call Test::More::plan_add(1) or something like this? > Consider the following. use Test::More; use Test::Warn::None; plan tests => 42; To make this work I'd have to overhaul the internal Test::Builder planning system to allow Test::Warn::None to say "I'm going to add an extra test, please remember this fact". I can be convinced its worth it. -- Life is like a sewer. What you get out of it depends on what you put into it. - Tom Lehrer
Re: [ANNOUNCE] Test::Warn::None 0.02
-BEGIN PGP SIGNED MESSAGE- Moin, On 23-Jun-03 Michael G Schwern carved into stone: > On Mon, Jun 23, 2003 at 05:49:06PM +0100, Fergal Daly wrote: >> I'm looking for comment or suggestions about this new module. It's >> independent of and complementary to Test::Warn. It tests that your test >> script didn't emit any warnings. Just add >> >> use Test::More::None; >> >> to the top your test script, update your plan (if you've got one) and >> that's >> it. You'll get an extra test, executed after your script ends checking >> whether there were any warnings. If there were you'll get a full run >> down of >> them including a stack trace. > > Good idea. Too bad about the plan calculation hackery necesssary. :( Can't nowarings() call Test::More::plan_add(1) or something like this? Cheers, Tels - -- Signed on Tue Jun 24 10:43:41 2003 with http://bloodgate.com/tels.asc perl -MDev::Bollocks -le'print Dev::Bollocks->rand()' widespreadedly supply compelling partnerships http://www.notcpa.org/ You have the freedom to run any code. Yet. http://bloodgate.com/perl My current Perl projects -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl. iQEVAwUBPvgPRXcLPEOTuEwVAQGjZwf9FOP5nCLq0biUbPAuoDst+KN/O5v8NaiD NNWp4Frp3cYiJ0WQDyRAuse9Slc0rLX9h0rxJCj1e8mKanO+Ey8lCUJJt4qG9C+5 hOacRQZ6eSh0Unb1WCAQAMXaMozC3kxgVZ/ArVRMG8Wqz843anaC0doDOHarK/BI he/gU0D+bPzycd7VwdxxTvmJSkvWfuPlhj4AvqCUXh/k/eBX44noa1PYTQgj6yKz nvba4OhadDe6bBLzeX3c/nrsgvCnF5Mh80mhQp9BS0oLm4yAa8jMliqI5/Y3nk88 d1nqoLtiJ6bBNiQmSz63q44GrOD/v5DfoR6bS4uNhqKaUbNmDrRYzQ== =KSIZ -END PGP SIGNATURE-
Re: [ANNOUNCE] Test::Warn::None 0.02
On Mon, Jun 23, 2003 at 05:49:06PM +0100, Fergal Daly wrote: > I'm looking for comment or suggestions about this new module. It's > independent of and complementary to Test::Warn. It tests that your test > script didn't emit any warnings. Just add > > use Test::More::None; > > to the top your test script, update your plan (if you've got one) and that's > it. You'll get an extra test, executed after your script ends checking > whether there were any warnings. If there were you'll get a full run down of > them including a stack trace. Good idea. Too bad about the plan calculation hackery necesssary. :( -- Me? A robot? That's rediculous! For one thing, that doesn't compute at all!
[ANNOUNCE] Test::Warn::None 0.02
Hi, I'm looking for comment or suggestions about this new module. It's independent of and complementary to Test::Warn. It tests that your test script didn't emit any warnings. Just add use Test::More::None; to the top your test script, update your plan (if you've got one) and that's it. You'll get an extra test, executed after your script ends checking whether there were any warnings. If there were you'll get a full run down of them including a stack trace. If there are parts of your script that should be emitting warnings then you should be using Test::Warn to capture them, the 2 modules should play nicely together. Full docs below. F NAME Test::Warn::None - Make sure you didn't emit any warnings while testing SYNOPSIS use Test::Warn::None; # do lots of testing DESCRIPTION In general, your tests shouldn't produce warnings. This allows you to check at the end of the script that they didn't. If they did produce them, you'll get full details including a stack trace of what was going on when the warning occurred. If some of your tests should produce warnings then you should be capturing and checking them with Test::Warn, that way Test::Warn::None will not see them and not complain. USAGE Simply by using the module, you automatically get an extra test at the end of your script that checks that no warnings were emitted. So just stick use Test::Warn::None at the top of your script and continue as normal. If you want more control you can invoke the test manually at any time with "had_no_warnings()". The warnings your test has generated so far are stored are in array. You can look inside and clear this whenever you want with "warnings()" and "clear_warnings()". However, it would be better to use the Test::Warn module if you want to go poking around inside the warnings. OUTPUT If warning is captured during your test then the details will output as part of the diagnostics. You will get: o the number and name of the test that was executed just before the warning (if no test had been executed these will be 0 and '') o the message passed to "warn", o a full dump of the stack when warn was called, courtesy of the "Carp" module EXPORTABLE FUNCTIONS had_no_warnings() This checks that there have been warnings emitted by your test scripts. Usually you will not call this explicitly as it is called automatically when your script finishes. clear_warnings() This will clear the array of warnings that have been captured. If the array is empty then a call to "had_no_warnings()" will produce a pass result. warnings() This will return the array of warnings captured so far. Each element of this array is a hashref with the following keys: o prev_test: the number of the test that executed before the warning was produced, if no tests had executed, this will be 0. o prev_test_name: the name of the test that executed before the warning was produced, if no tests had executed, this will be "". o msg: the captured warning message that your test emitted o carp: the captured warning message that your test emitted plus a stack trace generated by the Carp module. o stack_trace: A Devel::StackTrace object, created at the time of the warning. This will only be present if Devel::StackTrace is installed. PITFALLS When counting your tests for the plan, don't forget to include the test that runs automatically when your script ends. BUGS None that I know of. SEE ALSO Test::More, Test::Warn AUTHOR Written by Fergal Daly <[EMAIL PROTECTED]>. COPYRIGHT Copyright 2003 by Fergal Daly <[EMAIL PROTECTED]>. This program is free software and comes with no warranty. It is distributed under the LGPL license See the file LGPL included in this distribution or http://www.fsf.org/licenses/licenses.html.
