Re: Stupid prove tricks
On Wed, February 25, 2009 6:06 pm, Michael G Schwern wrote: > $ prove --exec 'cat -' test.dummy > test > > Now you can write TAP and finish with ctrl-d. But test.dummy has to > exist. /dev/null works for me. Perhaps you could post your tricks: http://perlmonks.org/?node=Meditations#post
Re: use-case for isnt()
On Thu, February 12, 2009 4:20 am, Gabor Szabo wrote:
> the one in the docs looks like this:
>
> # $foo isn't empty
> isnt( $foo, '', "Got some foo" );
>
> which feels such a weak test I don't think I'd write it.
Somewhat longer version of the same thing:
my $warn = '';
%SIG{__WARN__} = sub { $warn .= "@_" };
...
isnt( $warn, '', 'Unexpected warnings during test run' );
Re: Public Humiliation and Kwalitee (was Re: Tested File-Find-Object-0.1.1 with Class::Accessor not installed)
On Thu, October 23, 2008 10:37 am, chromatic wrote: > I don't care about backchannel communication between other authors and > CPAN > Testers, but how can you blame Shlomi for thinking that public humiliation > isn't a vital component of Kwalitee? There's prior art: > > http://cpants.perl.org/highscores/hall_of_shame That looks sorted by kwalitee and author. If we're shaming people, author name shouldn't be a factor. Could it be by kwalitee and most recent release date instead?
Re: TAP Frameworks Continue to Spread
Someone who's actually looked at this stuff may want to update http://en.wikipedia.org/wiki/Test_Anything_Protocol I think there's also stuff on that page that needs updating re: Test::Harness 3. On Tue, May 13, 2008 2:44 pm, chromatic wrote: > PHP's Symfony has a test framework called lime, based on Test::More: > > > http://www.symfony-project.org/book/1_0/15-Unit-and-Functional-Testing > > > I just heard about a C++ test framework based on lime called lemon: > > > http://eric.scrivnercreative.com/?p=8 > > > -- c > >
Re: W3C validator without network access?
On Sun, April 6, 2008 9:28 pm, Gabor Szabo wrote: > Is there a W3C validator that works locally on my computer? > > All the modules I found so far use the http://validator.w3.org/ service > including Test::HTML::W3C but that's not really usable in a frequently > running test suit. The source for that is available as described on http://validator.w3.org/source/
Re: W3C validator without network access?
On Sun, April 6, 2008 9:28 pm, Gabor Szabo wrote: > Is there a W3C validator that works locally on my computer? You mean an X?HTML validator? I haven't used it, but: http://htmlhelp.com/tools/validator/offline/index.html.en
Re: Why should package declaration match filename?
Eric Wilhelm gmail.com> writes:
> Aside: I have often wished that base.pm had simply said eval("require
> $base") and been done with it
http://search.cpan.org/perldoc/parent#HISTORY
Re: Dev version numbers, warnings, XS and MakeMaker dont play nicely together.
On Sun, January 6, 2008 4:54 pm, demerphq wrote: > So we are told the way to mark a module as development is to use an > underbar in the version number: > > $VERSION= "1.23_01"; > > > but this will produce warnings if you assert a required version number, as > the version isn't numeric. > > So the standard response is to do > > $VERSION= eval $VERSION; > > on the next line. This means that MakeMaker sees "1.23_01" but Perl > internal code for doing version checks sees "1.2301". This is all fine and > dandy with pure perl modules. > > BUT, if the module is "bog standard" and uses XS this is a recipe for > a fatal error. XS_BOOT_VERSIONCHECK will compare "1.23_01" to "1.2301" and > decide that they are different versions and die. See perlmodstyle: > If you want to release a 'beta' or 'alpha' version of a module but > don't want CPAN.pm to list it as most recent use an '_' after the > regular version number followed by at least 2 digits, eg. 1.20_01. If > you do this, the following idiom is recommended: > > $VERSION = "1.12_01"; > $XS_VERSION = $VERSION; # only needed if you have XS code > $VERSION = eval $VERSION;
Re: Summarizing the pod tests thread
On Tue, July 31, 2007 9:56 pm, chromatic wrote: > On Tuesday 31 July 2007 20:25:15 Salve J. Nilsen wrote: >> Turning off syntax checking of your POD is comparable to not turning on >> warnings in your code. Now would you publish code developed without >> "use >> warnings;"? > > Now that's just silly. Is it? Comparable. Capable of being compared. 1913 Webster. > I really have nothing more to say in this thread. Wow. It's one of those threads that I didn't even bother reading till now, since I felt pretty confident that I wasn't going to change my opinion (and that most others would not as well). Pity I broke down.
Re: What was I thinking?
Kirrily Robert wrote: > What I want to know is, should I just bin it? Or might it, in fact, be > useful to someone somehow? Or is it just bad form to completely delete > CPAN modules? I guess I could update it with a new version that says > "Don't use me." You could just put out a CPAN-Test-Reporter.txt file directing people to backpan.
Re: Eliminating STDERR without any disruption.
Michael G Schwern wrote: > print "TAP version 15\n"; > print "1..1\n"; > print "# Information\n"; > print "not ok 1\n"; > print "! Failure\n"; I'd really not like to see meaningful punctuation. How about "diag Failure\n". Or even levels of keywords debug/info/notice/warning/ err/crit/alert/emerg (stolen from syslog.h). Oh, and "yaml" if that idea lives.
Re: No, sending diag() to STDOUT won't work. Yet again.
chromatic wrote: > One issue that hasn't come up much is that you can't always rely on STDERR > being available when a human looks at the test results. > > Think of testing long-running programs in process, testing in the browser > (whether via JavaScript Test.Builder or Apache::Test), and automated smoke > tests. > > Sure, dumping diagnostics to STDERR works fairly well when a human enters > the > command to run the tests and sits in front of the controlling terminal and > can scroll back to see the STDERR output, but that's not the only case of > running tests at all (and getting diagnostic output is much, much more > useful > when you don't have access to the particular computer where the tests > fail). Another way of saying that is that TAP is at heart a file/stream format, and where it tries to be something else, it loses benefits that come with that (merging STDOUT/STDERR and the bailout function being two instances that spring to mind).
Re: The price of synching STDOUT and STDERR
David Cantrell wrote:
> Yitzchak Scott-Thoennes wrote:
>> David Cantrell wrote:
>>> Any test suite that blithely ignores warnings is BROKEN.
>>> The second type of warning is the one that tells you when you the
>>> author
>>> have fucked up, like, when you say "my $variable" twice, or saying
>>> "$variable = 'one thing'" and "$varable = 'something else'". I deal
>>> with those by having $SIG{__WARN__} turn them into die()s in the tests.
>>> If you don't deal with them, you're saying that you don't care about
>>> tripping yourself up in the future.
>> I have to disagree here. You are saying that it is the test's
>> responsibility to fail if it issues any warnings. I believe
>> an author may choose to scan the test output and rely on seeing
>> messages to go to stderr.
>
> Please, tell me how I can scan the test output on - say - Windows. Bear
> in mind that I do not own a Windows licence, nor do I have any hardware
> that will run Windows without lots of annoying faffing around.
You don't. Or you take the extra step to have your test detect and fail
on warnings. But there are downsides, see below.
> When a user installs my module on Windows, he will probably type
> something like:
>
> C:\> perl -MCPAN -e 'install Daves::Module'
>
> which will handle any dependencies for him. If my module - or one of
> the dependencies - spits out a warning, the user is likely to miss it
> when it scrolls past too fast to read. Even worse, he might see it, and
> ignore it because of the bit at the bottom that says "all tests passed".
>THAT is why I believe warnings in tests should be fatal by default.
I support your right to make your warnings fatal, but I'd not like
to see that become the default. New versions of perl can enable new
warnings. If you want to ensure that you are an early tester of new
perl versions against your modules, you can get by with having to
release new module versions as needed. But for the greater number
of perfectly decent modules out there that just sit unchanged for
years, it's too harsh to have them start failing tests out of the
blue.
> It means I am more likely to get useful bug reports. It also means I'll
> get "pro-active" bug reports from the CPAN testers.
>
> > Obviously it's better to do as you
>> propose, but that takes extra work in every test to implement.
>
> $SIG{__WARN__} = sub { die(@_) };
>
> so much extra work! Or if you're less of a depdencies-fascist than I
> am, use Test::NoWarnings for even less typing.
>
>> Authors should not be counted on to do so
>
> Authors are giving their work away for free. They shouldn't be counted
> on to do *anything*.
>
> >and when they don't
>> go that extra mile, their warnings should not just get lost.
>
> Of course. It would be nice if they weren't *ignored* though.
That's exactly what I'm saying; that changing from displaying STDERR
to silently suppressing it is a BAD THING(tm). I thought you were
arguing the opposite; that it's ok to do so because tests that don't
catch warnings are already broken.
> Hrrm, I'm going to go away now and think about how I can inject that
> __WARN__ handler into everyone elses tests when I run them :-)
sitecustomize.pl and $0 =~ /(?:\.t|test\.pl)\z/ ?
Re: The price of synching STDOUT and STDERR
> On 14 Mar 2007, at 07:29, chromatic wrote: >> The problem is that there's no way to tell that that information >> sent to >> Test::Builder->diag() is diagnostic information for the tests >> because once it >> goes out on STDERR, it could be anything. > > So we seem to have two reasonably sensible options on the table. I > don't think they're mutually incompatible. > > Ovid's 'only merge STDOUT and STDERR when in verbose mode' seems to > be workable with current Test::Builder. > > We should also push forward with machine readable diagnostics as a > formal part of TAP and have those show up on STDOUT along with all > the other TAP. > > Did I miss anything? A way to request verbose output without the merging.
Re: The price of synching STDOUT and STDERR
David Cantrell wrote:
> Michael G Schwern wrote:
>
>> First thing is breaks, and probably most important: No warnings.
>
> Any test suite that blithely ignores warnings is BROKEN.
>
> There are two types of warning. First, those which you deliberately
> spit out, like "use of foo() is deprecated, please use bar() instead".
> Your tests need to exercise that warning, so need to somehow capture
> them and check that they're spat out at the right time. If you don't do
> that, you're not testing properly.
>
> The second type of warning is the one that tells you when you the author
> have fucked up, like, when you say "my $variable" twice, or saying
> "$variable = 'one thing'" and "$varable = 'something else'". I deal
> with those by having $SIG{__WARN__} turn them into die()s in the tests.
> If you don't deal with them, you're saying that you don't care about
> tripping yourself up in the future.
I have to disagree here. You are saying that it is the test's
responsibility to fail if it issues any warnings. I believe
an author may choose to scan the test output and rely on seeing
messages to go to stderr. Obviously it's better to do as you
propose, but that takes extra work in every test to implement.
Authors should not be counted on to do so, and when they don't
go that extra mile, their warnings should not just get lost.
Re: The price of synching STDOUT and STDERR
chromatic wrote:
> On Wednesday 14 March 2007 01:37, Smylers wrote:
>
>> chromatic writes:
>
>> > There ought to be a way to capture diagnostic information in the TAP
>> > stream because it's useful for diagnosing problems.
>
>> Does that help with the case where it's an 'ordinary' Perl-generated
>> warning ("Use of uninitialized value" and the like), which runtests is
>> also swallowing at the moment?
>
> They don't have to interfere with the TAP stream unless they call
> Test::Builder->diag(), which was my laborious and heavily sarcastic point.
Seems to me an environment var set by default by TAP::Parser that makes
Test::Builder send diag output in the STDOUT TAP stream (plus a T::B method
to override the env var or lack thereof) would be much much better than
the problems that result from merging STDOUT/STDERR.
I know I've had problems in some past versions of cygwin when merging
stdout/stderr where merging happened at other than line boundaries,
which would really screw things up in terms of identifying what's TAP
and what's diagnostic.
Test::Builder: mixing use_numbers on and off
Test::Builder has a method use_numbers to turn off test numbering; this can be useful when running tests in different processes. But the doc says: > Most useful when you can't depend on the test output order, such as when threads or forking is involved. > > Test::Harness will accept either, but avoid mixing the two styles. > > Defaults to on. In a longer test script (doesn't "test program" sound silly?), I have only a short section that is potentially going to be out of order, so I want to say: $builder->use_numbers( 0 ); ... $builder->current_test( blah ); $builder->use_numbers( 1 ); around that section. This works fine with current Test::Harness. Is the "avoid mixing" warning out of date? Or in accord with future TAP plans?
Re: fetching module version from the command line
On Thu, Jul 13, 2006 at 02:29:38PM +0300, Gabor Szabo wrote: > On 7/13/06, Fergal Daly <[EMAIL PROTECTED]> wrote: > >I could change it so that it tries to figure out whether it's being > >used for real or not and disable the END block code but that's stress > >and hassle. As a module author, as far as I'm concerned, if MakeMaker > >can figure out my version then my job is done, > > So the only thing that would be correct is to search @INC for the .pm file > and then grep it with the same regex MakeMaker uses. That wouldn't be correct for modules that aren't the one that determine the distribution version, since other modules won't necessarily follow the one-line rule.
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On Sun, Apr 23, 2006 at 11:34:12AM +0200, Marcus Holland-Moritz wrote:
> On 2006-04-23, at 02:26:54 -0700, Yitzchak Scott-Thoennes wrote:
>
> > On Sun, Apr 23, 2006 at 11:01:17AM +0200, Marcus Holland-Moritz wrote:
> > > The only thing worth mentioning is that with perl 5.003,
> > > the following happens:
> > >
> > > [EMAIL PROTECTED] $ perl5.003 Makefile.PL
> > > Can't locate ExtUtils/Command.pm in @INC at Makefile.PL line 4.
> > > BEGIN failed--compilation aborted at Makefile.PL line 4.
> >
> > Yes, run-time "require VERSION" is almost always the wrong thing to do.
> >
> > > I'd suggest the following change:
> > >
> > > --- Makefile.PL.orig2006-04-23 10:58:31.0 +0200
> > > +++ Makefile.PL 2006-04-23 10:58:50.0 +0200
> > > @@ -1,4 +1,4 @@
> > > -require 5.004_05;
> > > +BEGIN { require 5.004_05 }
> >
> > "use 5.004_05;" would be better.
>
> No, it wouldn't.
>
> [EMAIL PROTECTED] $ head -n 5 Makefile.PL
> use 5.004_05;
>
> use ExtUtils::MakeMaker;
> use ExtUtils::Command qw( touch rm_f );
>
> [EMAIL PROTECTED] $ perl5.003 Makefile.PL
> syntax error at Makefile.PL line 1, near "use 5.004_05"
> Execution of Makefile.PL aborted due to compilation errors.
Which version is this? perlfunc for perl 5.003_07 claims use VERSION
works.
Re: Test me please: P/PE/PETDANCE/Test-Harness-2.57_06.tar.gz
On Sun, Apr 23, 2006 at 11:01:17AM +0200, Marcus Holland-Moritz wrote:
> The only thing worth mentioning is that with perl 5.003,
> the following happens:
>
> [EMAIL PROTECTED] $ perl5.003 Makefile.PL
> Can't locate ExtUtils/Command.pm in @INC at Makefile.PL line 4.
> BEGIN failed--compilation aborted at Makefile.PL line 4.
Yes, run-time "require VERSION" is almost always the wrong thing to do.
> I'd suggest the following change:
>
> --- Makefile.PL.orig2006-04-23 10:58:31.0 +0200
> +++ Makefile.PL 2006-04-23 10:58:50.0 +0200
> @@ -1,4 +1,4 @@
> -require 5.004_05;
> +BEGIN { require 5.004_05 }
"use 5.004_05;" would be better.
Re: Show-stopping Bug in Module::Install and the Havoc it Created
On Mon, Apr 03, 2006 at 10:32:12PM +1000, Adam Kennedy wrote: > Yitzchak Scott-Thoennes wrote: > >On Sat, Mar 11, 2006 at 10:20:29AM +0100, Tels wrote: > >>B when it breaks, end-users cannot fix the problem for themselves, they > >>need to bug the author and he has to release a new version. (Good luck > >>with that with sparsely maintained modules...) > > > >Last time this happened to me, I just replaced the bundled version > >with a newer one. No need to bug the author (though I did verify > >that others already had). > > > >(Since then, I've heard (but haven't confirmed) that just installing a > >newer MI and running Makefile.PL in the broken dist will do this > >automatically. Is this correct?) > > No, although if you delete the inc directory entirely, the Makefile.PL > should latch onto the system version and go into author mode, which for > the purposes of installation is almost entirely the same. Right, I meant to say deleting inc in there. > HOWEVER, that requires that they NOT be using a custom extension, and > than the commands used in the Makefile.PL match those in the current > version of Module::Install. Good to know, thanks. > The command list isn't entirely frozen yet, so while it may work, > there's some risks. > > Once the commands have frozen, this will be a lot safer to do. Assuming someone doing this has whatever is then the newest Module::Install, are there still command list issues?
Where did I see this use of plan()?
I remember working with some module that had tests something like:
use Test::More;
plan tests => numtests();
...
is($foo, $bar, 'foo is bar');
sub numtests { 13 }
So that when you added a new test to the bottom, the number to modify
was right there also. Ring a bell with anyone?
Re: Show-stopping Bug in Module::Install and the Havoc it Created
On Sat, Mar 11, 2006 at 10:20:29AM +0100, Tels wrote: > B when it breaks, end-users cannot fix the problem for themselves, they > need to bug the author and he has to release a new version. (Good luck > with that with sparsely maintained modules...) Last time this happened to me, I just replaced the bundled version with a newer one. No need to bug the author (though I did verify that others already had). (Since then, I've heard (but haven't confirmed) that just installing a newer MI and running Makefile.PL in the broken dist will do this automatically. Is this correct?)
Re: Request for Comments: Package testing results analysis, result codes
On Mon, Feb 20, 2006 at 11:36:27AM +, Barbie wrote:
> > 12. System is incompatible with the package.
> > Linux::, Win32::, Mac:: modules. Irreconcilable differences.
>
> Not sure how you would cover this, but point 12 seems to possibly fit.
> POSIX.pm is created for the platform it's installed on. A recent package
> I was testing, File::Flock (which is why I can't install PITA) attempted
> to use the macro EWOULDBLOCK. Windows doesn't support this, and there
> doesn't seem to be a suitable way to detect this properly.
use POSIX "EWOULDBLOCK"; $ok = eval { EWOULDBLOCK(); 1 }; print $ok
Re: Binary distributions
On Mon, Feb 06, 2006 at 08:16:11AM +0200, Offer Kaye wrote: > OT question - why is Scalar-List-Utils listed as "CORE"? It is not > part of the Perl5 core http://perldoc.perl.org/perl58delta.html#New-Modules-and-Pragmata
Re: [Module::Build] [RFC] author tests
On Thu, Feb 02, 2006 at 10:01:48AM -0800, Tyler MacDonald wrote: I strongly feel that authors should keep everything necessary for their distribution public; either in the CPAN distribution itself, or via a "permanent" publicly available version control system. Who's to say you won't lose interest in maintaining the module or in perl altogether at some point? Or move to Antarctica and be unable to maintain it? Or have your home/business or wherever your files are kept destroyed in a hurricane or other natural disaster? And, of course, we all will die someday. Some suddenly. I do agree that many (all?) of these tests are irrelevant to someone packaging your distribution. > Chris Dolan <[EMAIL PROTECTED]> wrote: > > * copyright.t - Ensures that there is a "Copyright ".([localtime]-> > > [5]+1900) somewhere in every .pm file. Will break 11 months from now. > > * distribution.t - Relies on Test::Distribution, which is not in my > > prereq list > > * perlcritic.t - Runs Test::Perl::Critic on all .pm files. Will > > fail without my specific $HOME/.perlcriticrc "Test::Perl::Critic allows you to configure Perl::Critic by passing the path to a F file in the C pragma. For example: use Test::Perl::Critic (-profile => 't/perlcriticrc'); all_critic_ok();" Probably you'd like this to keep in sync with any changes to your .perlcriticrc, which may require some changes to your Makefile.PL/ Build.PL. > > and will fail with future, more exhaustive versions of P::C It would be nice if there was some way to indicate which version of P::C was expected to pass, and TODO any newly looked for problems. > > * spelling.t - Runs Test::Spelling. Will fail without my custom > > dictionary There's Test::Spelling::add_stopwords and =for stopwords. These should be used as much as possible instead of adding to your custom dictionary. But at least your custom dictionary is recreatable (because all the needed words are included in your pod :) should someone else pick up maintenance of your distribution. > > * versionsync.t - Checks that the $VERSION is the same in all bin/* > > and *.pm files. This test is pointless after release, since it's > > already been tested before release > > * pod.t - Checks POD validity. This test is pointless after > > release, since it's already been tested before release > > * pod-coverage.t - Checks POD completeness. This test is pointless > > after release, since it's already been tested before release > > > > and one I have not yet employed: > > * coverage.t - Ensures that Devel::Cover totals are higher than > > some threshold > > Wow, you really *are* exhaustive. How do you find the time to write any > code? ;-) > > Now that I understand exactly what you mean by "author" tests, here's what I > think: Whatever convention you're using, if these tests are only going to > work on your system, then they definately shouldn't be in "t". And since > there's absolutely no value in these types of tests for anybody else except > the module author, there's no real point in having a convention, just stick > 'em anywhere that the make/buildfiles will ignore them. I disagree; presumably anyone running disttest would want these tests run, so they belong in t and named .t, with an appropriate skip_all at the top. Does anyone have a problem with disttest setting PERL_TEST_EXHAUSTIVE? Or a suggestion for a better name? Chris, how are you currently set up to run these tests only when preparing a release?
Re: [Module::Build] [RFC] author tests
On Thu, Feb 02, 2006 at 02:56:09AM -0800, Tyler MacDonald wrote: > A new module doesn't need to be added to the core, so long as there > is a way that we can reliably detect when a person wishes to build and test > any given perl package for an objectively unselfish purpose such as > 1:prepackaging, 2:automated testing, or 3:releasing. All three are viral so > it's best to make sure they do no harm, while still maintaining some level > of convenience for the "end user". > > There's already AUTOMATED_TESTING for 2 and "make disttest" for #3 > (just keep a file around in your repo that's not in your MANIFEST and test > for it's presence.) > > Any good way to detect #1? An environment variable. PERL_TEST_EXHAUSTIVE? And make/Build disttest can set it too. In the perl core, the few tests that are normally not run are requested by a -torture switch. But I think despite this precedent exhaustive sounds better. But please, lets not have new ta/ or whatever directories or .ta files; this is a problem that is well taken care of with skip_all. If somebody really wants, they could go the Test::Exhaustive route, which would automatically do the skip_all if the env vars weren't set. But putting a few stock lines at the start of your .t file isn't really all that big a deal.
Re: YAML and Makefile.PL (was various topics)
On Sun, Jan 29, 2006 at 12:04:22PM +0100, Tels wrote: > Just witness Graph::Dependency, it will fail when their is no META.yml > available, and what do you want me to do then? Parse Makefile.PLs? The "correct" WTDI is to execute the Makefile.PL and parse the resulting Makefile, looking for the PREREQ_PM line.
Re: Dependency trees and ppm
On Sat, Jan 28, 2006 at 12:02:41AM +0100, Tels wrote: > Moin, > > On Friday 27 January 2006 23:43, Tyler MacDonald wrote: > > Jeffrey Thalhammer <[EMAIL PROTECTED]> wrote: > > > Randy Kobes distributes Win32 PPMs for some of the > > > modules that ActiveState doesn't provide. It is not > > > entirely automated, so the latest code isn't always > > > available. But Randy is very helpful if there's > > > anything you want to see. > > > > > > http://theoryx5.uwinnipeg.ca/ppms/ > > > > What is actually happening on ppm.activestate.com, is that only > > modules that pass all their unit tests are packaged for the general > > public. IMHO this is a great idea, since then people who are "ppm > > installing" stuff from activestate repoes can be reasonably(*) > > confident that the package will work on their system. > [snip a bit] > > Yes, but most modules shouldn't (or don't) fail tests. And yet Math::Big > for instance can't be build by ActiveState for linux :-/ > > It would be good if first pure-perl modules that don't require much to > work (like Math::BigInt::foo) could be made to work :) > > See here: > > http://ppm.activestate.com/BuildStatus/5.8-linux/linux-5.8/Math-BigInt-Constant-1.06.txt > > That shouldn't happen. Yikes, that's perl 5.8.0! What is that about? Looking in the http://ppm.activestate.com/BuildStatus/5.8-linux/linux-5.8/ directory, I don't even see any attempt to build the required newer version of Math-BigInt. Very strange.
Re: Fwd: CPAN Upload: D/DO/DOMM/Module-CPANTS-Analyse-0.5.tar.gz
On Fri, Jan 27, 2006 at 03:42:58PM +0100, Tels wrote: > On Thursday 26 January 2006 15:26, Thomas Klausner wrote: > > I just uploaded Module::CPANTS::Analyse to CPAN. MCA contains most of > > the previous Kwalitee indicators and some code to check if one > > distribution tarball conforms to those indicators. It also includes a > > script calls cpants_lint.pl which is basically a frontend to the > > module. > > Very cool. > > However, I am _really really_ starting to wonder whether we need a > Kwalitee rating based on *excessive usage of prerequisites*. How about two; one, a point for not having lots of prerequisites, and another, a point for having lots of prerequisites. Where lots is defined as the same number in both cases.
Re: Test Script Best-Practices
On Tue, Jan 24, 2006 at 10:25:44PM -0500, David Golden wrote:
> Jeffrey Thalhammer wrote:
> >* Should a test script have a shebang? What should it
> >be? Any flags on that?
>
> I often see "-t" in a shebang. One downside of the shebang, though, is
> that it's not particularly portable. As chromatic said, with "prove"
> it's not really necessary. ("prove -t")
-T or -t in a shebang tells Test::Harness or perl's TEST that perl
needs to be run with that switch for the tests to test what they are
supposed to test.
Re: SKIP blocks and the debugger
On Mon, Jan 09, 2006 at 07:06:08PM +1100, Kirrily Robert wrote:
> Does anyone else find that SKIP: { } blocks bugger up the debugger?
> I'll be happily bouncing on the "n" key to get to round about the
> vicinity of the failing test, and then blam, it sees a skipped test
> and just fast-forwards to the end.
Yup. I assume "n" just puts a breakpoint on the next statement, but
skip() bypasses said statement. Use a "c nnn" where nnn is the line
number of the statement after the skip block.
Re: How to test an overloaded @{} operator?
On Sun, Oct 02, 2005 at 01:42:05PM +0200, Torsten Schoenfeld wrote:
> On Fri, 2005-09-30 at 14:40 -0700, chromatic wrote:
>
> > Does doing it in two steps work? Instead of:
> >
> > > is_deeply ($obj->get ('some_flags'), ['value-one', 'value-two']);
> >
> > perhaps:
> >
> > my @flags = @{ $obj->get( 'some_flags' ) };
> > is_deeply( [EMAIL PROTECTED], [ 'value-one', 'value-two' ] );
>
> Yep, that works. As Schwern said, this is probably the only workable
> solution. Looks like I'll have to change quite a few tests to use this.
If you have quite a few tests to change, you may want to just do:
is_deeply( [EMAIL PROTECTED] $obj->get( 'some_flags' ) }, [ 'value-one',
'value-two' ] );
Re: Test::Exception and XS code
On Mon, Aug 15, 2005 at 05:58:23PM +0200, S?bastien Aperghis-Tramoni wrote:
> use strict;
> use Test::More tests => 2;
> use Test::Exception;
> use Net::Pcap;
>
> throws_ok(
> sub { Net::Pcap::lookupdev() },
> '/^Usage: Net::Pcap::lookupdev\(err\)/',
> "calling lookupdev() with no argument"
> );
>
> throws_ok
> { Net::Pcap::lookupdev() }
> '/^Usage: Net::Pcap::lookupdev\(err\)/',
> "calling lookupdev() with no argument"
> ;
> Now, if I move the "use Test::Exception" inside an eval-string and
> execute the new script:
>
> $ perl -W exception.pl
> 1..2
> ok 1 - calling lookupdev() with no argument
> Usage: Net::Pcap::lookupdev(err) at exception.pl line 13.
> # Looks like you planned 2 tests but only ran 1.
> # Looks like your test died just after 1.
>
> Aha! The first test, which uses the normal form of throws_ok() passes,
> but the second one, which uses the grep-like form, fails.
The throw_ok { ... } syntax only works because the throw_ok sub exists
and has a prototype that specifies a subref is expected; if you don't
load Test::Exception by the time the throw_ok call is compiled, it
is parsed as an indirect object call of the "throw_ok" method on the
object or class returned by the {} block:
$ perl -MO=Deparse,-p -we'throws_ok { Net::Pcap::lookupdev() } "/^Usage:
Net::Pcap::lookupdev\(err\)/", "calling lookupdev() with no argument"'
BEGIN { $^W = 1; }
do {
Net::Pcap::lookupdev()
}->throws_ok('/^Usage: Net::Pcap::lookupdev(err)/', 'calling lookupdev() with no
argument');
-e syntax OK
which is perfectly valid perl, but unlikely to do what you want.
Re: [ANNOUNCE] Test::Symlink
On Tue, Jul 05, 2005 at 04:52:34PM -0700, Michael G Schwern wrote: > I think you're using export_to_level() wrong. $self should really be $class > for starters. And the way you're using it symlink_ok() always gets > exported even if the user says "use Test::Symlink ()". You should be passing > it: For "use Test::Symlink ()", no import is even called.
Re: what slow could be in Compress::Zlib? (was RE: 5.004_xx in the wild?)
On Mon, Jul 04, 2005 at 02:19:16PM +0100, Paul Marquess wrote: > Whilst I'm here, when I do get around to posting a beta on CPAN, I'd prefer > it doesn't get used in anger until it has bedded-in. If I give the module a > version number like 2.000_00, will the CPAN shell ignore it? This is often done incorrectly. See L for the correct WTDI: $VERSION = "2.000_00";# let EU::MM and co. see the _ $XS_VERSION = $VERSION; # XS_VERSION has to be an actual string $VERSION = eval $VERSION; # but VERSION has to be a number Just doing $VERSION = 2.000_00 doesn't get the _ into the actual distribution version, and just doing $VERSION = "2.000_00" makes use Compress::Zlib 1.0; give a warning (because it does: 1.0 >= "2.000_00" internally, and _ doesn't "work" in numified strings). But if you are doing a beta leading up to a 2.000 release, it should be numbered < 2.000, e.g. 1.990_01. Nothing wrong with a 2.000_01 beta in preparation for a release 2.010 or whatever, though.
Re: Fwd: [EMAIL PROTECTED]: Re: fixing is_deeply]
On Sun, Jul 03, 2005 at 01:53:45PM +0200, demerphq wrote: > Actually about the only thing that seems to be really "hard" is doing > comparison of blessed regexes with overloaded stringification. For > that you need XS if you want it to work always. Now there's a sick idea. If blessed regexes with overloaded stringification actually work (that is, the actual regex is accessible to some part of the perl code), perhaps you could "fix" perl to use the stringification instead? Then you wouldn't have to worry about it :)
Re: Fwd: [EMAIL PROTECTED]: Re: fixing is_deeply]
On Sat, Jul 02, 2005 at 12:24:12AM -0700, chromatic wrote: > On Sat, 2005-07-02 at 08:55 +0200, demerphq wrote: > > > The entire basis of computer science is based around the idea that if > > you do the same operation to two items that are the same the end > > result is the same. Without this there is no predictability. No > > program could ever be expected to run the same way twice. > > Throw in some sort of external state and you have exactly that. > > Perhaps the name of is_deeply() is misleading, but I don't understand > why the argument about whether container identity should matter to the > function is so important. I expect the following test to pass: > > my $a = \1; > my $b = \1; > is_deeply( $a, $b ); > > Should it not? The values are the same, as are the types of the > containers, but the containers are different. It should, but is_deeply( [\1, \1], [(\1) x 2] ) should fail.
Re: [EMAIL PROTECTED]: Re: fixing is_deeply]
On Fri, Jul 01, 2005 at 05:57:51PM +0200, demerphq wrote: > On 7/1/05, David Landgren <[EMAIL PROTECTED]> wrote: > > demerphq wrote: > > > it is important that this is debated outside of just the perl-qa list > > > (its not that high traffic or visibility IMO) so I have taken the > > > liberty of starting a thread on Perlmonks about this. It is at > > > http://perlmonks.org/index.pl?node_id=471639. > > > > Ohh, that'll make schwern happy :) > > Heh. One day hopefully Schwern will get over his apparent prejudice > about the place. Though at first, I had the same thought as David, I don't think Schwern really has shown a prejudice against perlmonks. He just doesn't like (with good reason) bug reports going there instead of to the module author.
Re: Fwd: [demerphq@gmail.com: Re: fixing is_deeply]
On Fri, Jul 01, 2005 at 07:11:26AM +, Smylers wrote: > > To me 'deeply' implies recursing as deep as the data structure goes, not > that there's a special rule for the top-level that's treated differently > from the others. Nobody is saying is_deeply shouldn't be deep. If I understand correctly, is_deeply($a,$b) on a deep structure can still return ok if $a and $b have no references in common; it's not the specific value of the references that needs to match, it's the patterns of which parts within each of $a and $b have duplicate references, and whether those patterns match between the two. Another way of looking at it is that Schwern is saying is_deeply returns ok if the leaf values and overall structures match so long as no changes are made, while Yves is saying is_deeply should return not ok if the same change made to both ends up with different leaf values or overall structure.
Re: Fwd: [EMAIL PROTECTED]: Re: fixing is_deeply]
On Thu, Jun 30, 2005 at 05:09:39PM -0700, Michael G Schwern wrote: > > So, I conclude that is_deeply()'s behavior is ok and something like > Test::Deep should be enhanced with an option to deal with this > problem. So, am I correct in understanding that is_deeply will only notice value differences, if all the reference types are the same? And Yves's proposal is that patterns of which references are dups must also match? And that you feel an option to do it the latter way would belong in Test::Deep?
Re: Why a scoreboard?
On Sat, Apr 02, 2005 at 10:43:57AM -0500, Ricardo SIGNES wrote: > * "David A. Golden" <[EMAIL PROTECTED]> [2005-04-02T05:27:18] > > Andy Lester wrote: > > >Why is there a scoreboard? Why do we care about rankings? Why is it > > >necessary to compare one measure to another? What purpose is being > > >served? > > > > Why is there XP on perlmonks? Or Karma on Slashdot? Or for that > > matter, why do we grade students' exams (particularly, why do we often > > grade them on a curve)? > > This is not a good analogy to Kwalitee, because XP and Karma are > primarily awarded by humans who can make judgements based on reason. I think you are thinking of Reputation (which a node has), not XP (which a user has). In point of fact, XP can be awarded for logging on daily, for voting on other people's nodes, or even for cash contributions, not just for others' votes on one's own nodes.
Re: Kwalitee and has_test_*
On Fri, Apr 01, 2005 at 09:00:17PM +0200, Thomas Klausner wrote: > Well, kwalitee != quality. Currently, kwalitee basically only says how > well-formed a distribution is. For my definition of well-formed :-) But I'm > always open to suggestion etc. Since you ask... An important part of kwalitee to me is that Makefile.PL / Build.PL run successfully with stdin redirected to /dev/null (that is, that any user interaction be optional). Another is that a bug-reporting address or mechanism (e.g. clp.modules or cpan RT) be listed in the README or pod.
Re: Test::META
On Mon, Mar 28, 2005 at 08:35:34PM -0800, Michael G Schwern wrote: > > Whether things that are required for *testing* belong in > > build_requires really depends on whether you view testing as an > > integral part of the build process. This is something that is likely > > to depend on the *builder*, not the module author, which is, in my > > mind, the only argument (and a good one) for a separate test_requires. > > The distinction between build_recommends and and a possible > > test_recommends is more ambiguous. > > I agree with this, however I don't really see the ambiguity about > test_recommends. "ambiguous" was the wrong word to use, sorry. I just meant that the argument for separating out test_requires is a lot stronger than for test_recommends; I'd like to see them both, but I had the impression public opinion was weighted against them, so I was trying to argue for the more important one.
Re: Test::META
On Mon, Mar 28, 2005 at 03:10:52PM -0800, Michael G Schwern wrote: > On Mon, Mar 28, 2005 at 08:42:50AM -0500, Christopher H. Laco wrote: > > That's another gripe of mine about M::B and create_makefile_pl. > > It puts the requires AND build_requires in the PREREQ_PM in the > > Makefile.PL, which I won't want; nor do I think it right for everyone. > > There is no build_requires or recommends equivalent in MakeMaker, nor will > there be, Too bad. Seems to me it would make sense to have MakeMaker support adding the tags to META.yml. Don't see what other MakeMaker change would be needed. Maybe that presupposes something else that I see as very desirable: META.yml being (re)generated by Makefile.PL at build time, and CPAN* looking in META.yml instead of Makefile for prereqs. > so putting it into PREREQ_PM is the best thing to do. That's > what every MakeMaker-based module on CPAN does after all. > > Its better than just dropping it and having the build fail. > > > > Take Test::More for example. It's usually a build_requires and the other > > Test* things like Test::Strict, Apache::Test, etc are in recommends. > > Test probably won't run with Test::More, but skipping a few subtests > > based on recommends is ok. But I don't think build_requires should be a > > PREREQ_PM requirement at all. > > *scratch head* but if you don't have the modules necessary to BUILD the > module (as opposed to those necessary to run it)... how are you going to > build it? The distinction between PREREQ_PM and build_requires only becomes meaningful for binary (that is to say, pre-built) distributions. Such distributions should be able to rely on PREREQ_PM to indicate what other (binary) distributions are required. Whether things that are required for *testing* belong in build_requires really depends on whether you view testing as an integral part of the build process. This is something that is likely to depend on the *builder*, not the module author, which is, in my mind, the only argument (and a good one) for a separate test_requires. The distinction between build_recommends and and a possible test_recommends is more ambiguous.
Re: testing non-modules
On Sun, Mar 06, 2005 at 10:32:26AM -0800, Michael G Schwern wrote:
> #!/usr/bin/perl -w
>
> use Getopt::Long;
>
> my %Opts;
> GetOptions(\%Opts, "test");
>
> sub main {
> return if $Opts{test};
>
> ...the program using the functions below...
> }
> main();
>
> sub some_function { ... }
> sub some_other_function { ... }
I'd make that just:
sub main {
...the program using the functions below...
}
main() unless caller;
sub some_function { ... }
sub some_other_function { ... }
Re: dor and backwards compat (was Re: [ANNOUNCE] Test::Simple 0.49)
On Mon, Oct 18, 2004 at 01:05:06PM -0400, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 18, 2004 at 04:43:12PM +0200, H.Merijn Brand wrote:
> > > Please consider 0.50 very soon, in which you fix 'err' calls that are an
> > > obvious mistake given defined-or functionality in blead and 5.8.x-dor:
> >
> > That would be too easy to call. here's a patch ...
>
> Thank you. Patch provisionally rejected. Here's why.
>
> By adding a new keyword dor has broken backwards compatibility. Test::More
> is doing nothing wrong by current standards. main::err() is fully declared
> before its use. There is no ambiguity.
>
> Now with dor its suddenly a keyword and code breaks at no fault to the
> programmer. Its not just a warning, its a syntax error. Upgrading from 5.8
> to 5.10 will break code. This is a problem. Its a problem every time we
> add a new keyword.
FWIW, "err" is a second-class keyword. This means that an imported function
( or even *err = sub { ... } ) will take precedence over the keyword.
Does anyone know the history of other keywords that have been added? Seems
like there haven't been any in a long while except for "lock", which *was*
done in a backward-compatible the way M. Schwern suggests for err, but IIRC
not in an extensible way that could easily be applied to other new keywords.
Re: Hoplites: Watch for "each"
On Tue, Nov 04, 2003 at 07:18:34AM +0530, Abhijit Menon-Sen <[EMAIL PROTECTED]> wrote:
> At 2003-11-03 21:35:22 +, [EMAIL PROTECTED] wrote:
> >
> > > Just wondering, is keys() optimized for void context?
>
> Yes. From doop.c:Perl_do_kv:
>
> OP *
> Perl_do_kv(pTHX)
> { ...
>
> keys = hv;
> (void)hv_iterinit(keys);/* always reset iterator regardless */
>
> if (gimme == G_VOID)
> RETURN;
But be aware that it is also optimized for scalar context only if the
hash isn't tied.
