Re: TAP extension proposal: test groups
>> Anything else >> Any output line that is not a plan, a test line or a diagnostic is >> incorrect. How a harness handles the incorrect line is undefined. >> Test::Harness silently ignores incorrect lines, but will become more >> stringent in the future. This leads me to another question -- what to do about output that the program prints to STDOUT or STDERR? There are some modules that I use that insist on C-ing whenever something weird happens... will these mess up my tests? (They don't *now*, but that's because Test::Harness is being overly nice.) What would happen if TAP dictated that TAP output be sent to an extra filehandle? For example, prove could open filehandle 3, fork the test process, and collect TAP data on descriptor 3 while the usual program output is written to STDOUT and STDERR. This would make diagnostic output easier; it's just a normal print statement. If you wanted to truly please DJB (with his "don't parse" mantra), then you could open two extra filehandles, one for 'ok' and one for 'not ok', and print the number of the test mod 256 (i.e. one byte per test, no newline; just the byte) to each handle. If it comes in on pipe one and the number is where it should be, it's a 'ok #', if it comes in on that second pipe, it's a 'not ok #'. Now that I think about it, though, I'm not sure if this causes problems or solves problems. :) Comments? Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
Module Signatures [was Re: On "Gaming" CPANTS...]
> It adds a dependency on a binary application (gpg) that users have to > install by hand, doesn't check for the presence of it properly, and if > you don't have it, installs an enormous chain of dependencies, with said > deps having some major issues of their own. > > It's become bad enough that Module::Signature is being pulled from > Bundle::CPAN and being disabled by default in CPAN.pm, until > Module::Signature gets a maintainer capable that can make it somewhat > saner. I think the solution (to dependency hell) is to dictate that CPAN modules be signed with a standard algorithm. OpenPGP allows too many different algorithms, hence the 22 modules Crypt::OpenPGP is dependent on. The only strong reason to stick with OpenPGP is that it has the whole web-of-trust and keyserver infrastructure. If we can live without that, then I could write a small "cpansign" script that just uses Crypt::DSA to sign the distribution, and then have Module::Signature just verify that DSA signature. There's still a dependency issue, but 21 fewer of 'em. DSA can be made to be portable if it isn't already. (RSA is fine too, then I could sign my modules with my OpenPGP smartcard ;) If we adopted this scheme, maybe we could just have authors upload their keys to PAUSE (or some other "Trusted Source"), and have people that want to verify distributions pull the keys down from there. The disadvantage of this is that the PAUSE master could forge distributions, as could someone performing a MITM attack on your key download. However, this could all happen anyway. I have a few keys of CPAN authors in my keyring, but I've never verified the fingerprints in real life... so for all I know, someone could be tampering with my distributions as we speak. This message might not really be from Jon Rockway :) On a related note, I sent some patches in to the Crypt::OpenPGP author a while ago but never heard anything back. Is that module still being maintained? Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
Re: Testing various HTML constructs
Andy Lester wrote: > > On Jul 8, 2006, at 10:31 PM, Michael G Schwern wrote: > >> If your XPath parser balks at non-XHTML HTML then just run it through >> HTML::Tidy->clean which will convert it to XHTML. > > Usually. If usually isn't good enough, you can always write your own HTML converter with HTML::TreeBuilder. I do this in my blog software: http://trac.jrock.us/trac/blog_software/browser/lib/Blog/Format/HTML.pm This has the added advantage of allowing you to remove "nasty" HTML, if that's relevant in your application. Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
Re: TAP diagnostic syntax proposal
I can see why we wouldn't want to include YAML, and won't cry for *too long* if it doesn't go in ;), but here are some reasons why I'd like for full YAML to be a part of the spec: - marshaling data structures between the application being tested and the test harness (strings are nice, but full Perl/!!YAML objects are nicer) - infinite extensibility (then again, it was a little bit too easy for people to add to HTML, and look at what that got us) I just think having all of YAML at our disposal would let test authors and test harness authors do pretty much anything they want. YAML is pretty hard to parse, but fortunately the Hard Work has been done for us. YAML::Syck supports all the YAML we need and it has bindings for pretty much every language. I wouldn't call it lightweight, but the 300k of additional memory it uses is worth the potential benefits. I dunno, maybe I *am* overthinking this. It's just TAP. I guess what I really want is for the perl interpreter to be able to serialize itself so I can debug failing tests more easily. That's not really a TAP issue,though :) Regards, Jonathan Rockway Adam Kennedy wrote: > Whoa whoa whoa slow down there folks... > > Some people seemed to have misrecognised those keys as YAML. > > It was NEVER meant to be YAML. > > The idea was to use something more like MIME headers. > > We all agreed that we DIDN'T want the format to be too heavy, and going > with MIME or MIME-alike seemed the sweet spot in terms of ease of > parsing and standardization vs extensibility. > > Having YAML in the TAP spec would complicate things greatly, especially > as the YAML spec includes things like multi-line strings. And it would > mean that we'd have to deal with YAML error events, JSON-style parsing > and a bunch of other things that are problematic. > > It's NOT ease to parse at all, not compared to the current relative > simplicity of TAP at the moment. > > Adam K > > Jonathan T. Rockway wrote: >>> not ok 2 - omg t3h sooper test!!1! >>> --- TAP diagnostics >>> file:foo.t >> >> >> Why aren't we commenting the YAML block so that it's compatible with >> current TAP parsers? I'm thinking something like this: >> >> not ok 2 - ensure that foo is equal to bar >> # --- !!tap/diagnostics >> # file: foo.t >> # line: 42 >> # got: >> # - !!perl/foobar >> # key: value >> # expected: >> # - !!perl/foobar >> # key: ~ >> # etc: (and so on) >> >> The commented section is raw YAML goodness, AND this format is >> compatible with current TAP parsers. I'm liking this a lot, >> especially since I can use it Right Now (tm) by doing diag(Dump($data)). >> >> Any reason this shouldn't be the standard? It's easy to parse, it's >> easy to read. >> >> Would it be acecptable if I patched Test::More to start outputing it's >> expected/got messages in YAML instead of a plain text format? >> >> Regards, >> Jonathan Rockway > signature.asc Description: OpenPGP digital signature
Re: TAP diagnostic syntax proposal
if i recall correctly, syck doesn't handle utf-8/16. does/will tap care about that? That's true -- I think Audrey patched the perl version to work properly, but I forgot that other languages are without that functionality. Ruby doesn't properly support Unicode either, so Unicode support probably doesn't matter to them. (I think Syck is originally a Ruby project, and Ruby has some moral qualm with Unicode, so that's why Syck doesn't work with Unicode.) As for Python, dunno. I do actually do test UTF-8 data structures in some of my tests, so this is actually a relevant concern. I think things will work fine if you're just outputting UTF8 data to your UTF8 terminal, but if you're doing colation or charset conversion (maybe your terminal is EUC_JP for example), then you'll run into problems. This is something to look into, if we want YAML TAP to work for languages other than Perl. What else is TAP targeted to? C / C++ / Java? oh, and while i'm thinking about it, i think it would be wise to include a tap version in the tap header, so as this protocol changes, parsers will have a chance to handle different tap versions gracefully. Good idea.
Re: TAP diagnostic syntax proposal
Aside from the fact that many languages are already using the TAP protocol and we'd create something they *don't* use, what happens when my 4,000 test lines all of a sudden become 16,000 test lines because the format has been changed? Do you pay for CPU time on a per-newline basis? :) Good point, though. If we put YAML in comments then we remain compatible with all past parsers and emitters. However, most perl tests don't care about TAP, they use Test::More and Test::Harness and happen to exchange data via TAP. If Test::More and Test::Harness decied to use "YAP" (YAML Anything Protocol? :), then most applications would probably never notice. However, emitting a raw YAML stream means that the application can never emit any other output, otherwise the YAML will become invalid. If we use comments and --- ..., then non-TAP output should still be acceptable. OK, you've convinced me. All-YAML TAP isn't a good idea. I might play with it a little more though, just for fun. Regards, Jonathan Rockway
Re: TAP diagnostic syntax proposal
Did you guys consider the problem of newlines in content? This is a good question. Implementing your own file format means you have a big-bag-o-quoting problems. How do you print a verbatim newline? What about a verbatim single quote? What about Unicode? What about a new line then "not ok - ++$counter"? :) http://cr.yp.to/qmail/guarantee.html says: When another programmer wants to talk to a user interface, he has to /quote/: convert his structured data into an unstructured sequence of commands that the parser will, he hopes, convert back into the original structured data. This situation is a recipe for disaster. The parser often has bugs: it fails to handle some inputs according to the documented interface. The quoter often has bugs: it produces outputs that do not have the right meaning. Only on rare joyous occasions does it happen that the parser and the quoter both misinterpret the interface in the same way. Things to think about :) Regards, Jonathan Rockway
Re: TAP diagnostic syntax proposal
While I agree with David, this argument is almost completely pointless.
Nobody reads the raw TAP output! If you want your TAP harness to
display "got" and "expected", let it. If you want it so say "foo" and
"bar" (so they line up :-P), then great.
The actual TAP is going to live in a protocol document for implementers
to read. The end-user will likely be using a harness and Test::More (or
$LANGUAGE_OF_CHOICE equivalent), so this doesn't matter at all. TAP
will be equally useful whether or not we use "got" and "expected".
When was the last time you netcat'd to slashdot to get the list of
articles? Never? Exactly -- because you have software to handle the
protocol for you. (Yes, yes, people telnet to port 80 and type "GET /"
or whatever to debug their server. But it's not normal behavior, and
99.99% of HTTP users have no idea what an HTTP header even is.)
Regards,
Jonathan Rockway
David Landgren wrote:
demerphq wrote:
On 7/12/06, Smylers <[EMAIL PROTECTED]> wrote:
David Landgren writes:
> Expected and actual has a long tradition in scientific endeavour,
And are still sucky as they are different lengths meaning the two
outputs are offset on the screen making it harder to see the failure.
Yves, that is absolute nonsense. The current output already has it
that way:
% perl -MTest::More -e 'plan(tests => 1); is("slothrop", "porpentine")'
1..1
not ok 1
# Failed test in -e at line 1.
# got: 'slothrop'
# expected: 'porpentine'
# Looks like you failed 1 test of 1.
They look lined up to me.
They strike me as the teams most intuitively recognizable and least
open
to misinterpretation.
I choose to disagree.
I think its more important to instantly see the difference between two
simple outputs than it is to use the most absolutely appropriate
terms.
But you cannot instantly see with what you suggest, since the two
words are *exactly the same length*!
With 'expected' and 'actual', the lengths are different, that's the
whole point. And of course, they would be appropriately
right-justified to line up their values.
Also how can people misinterpret:
Want: X
Have: Y
They are not very typographically distant.
David
Re: TAP diagnostic syntax proposal
are you serious? listen to what they people here are saying - we _all_ read the raw TAP output, all the time, and not because we're TAP developers interested in the underlying implementations. as users, the (current) raw TAP diagnostics helps us figure out why a test failed, and if it doesn't make sense due to bad wording or reversed expectations then it's that much harder than it needs to be. No, you're reading diagnostic output that your program prints. "got" and "expected" aren't part of TAP, they're comments in the TAP stream that some emitters emit and that harnesses print. Look at the TAP grammer here: http://svn.perl.org/parrot/trunk/examples/pge/grammars/TAP.pg There's no "got" or "expected" part of TAP, there's "ok 1" "not ok 3", "1..34", and "# this is a comment". So if we're going to add this to TAP, which I think is the whole point of this thread, then it doesn't matter what it's called. Your tap parser just needs to pick out a token, and throw a certain event if it finds that. It's up to the TAP harness (a level or so above the lexer/parser) to print "got: foo" "expected: foo". So if you don't like "got" or "expected", that's fine, just change the harness. I'm sure in some instances there won't be even be a line like that printed -- there will be a HTML table or something. That's the advantage of making these part of the TAP protocol; you won't have to worry about the semantics of "got" or "expected"... that will all be handled for you by the parser and then be presented nicely. To summarize, right now "got" and "expected" are artifacts of Test::More (etc.), not the TAP protocol. Regards, Jonathan Rockway
Re: TAP diagnostic syntax proposal
wow, my code is being used in a flame war! *blush* :-) Sorry! I didn't want this to come across as a flame. I just wanted to make sure I (and other people ;) have the distinction between TAP and uses of TAP clear in their minds. The sooner we can agree over what the protocol should call "got" and "expected", the sooner we can write a TAP harness that conveys that meaning to the end-user in whatever language they prefer. :) To summarize. What TAP uses is irrelevant, as long as it works. What the Harness prints is relevant, but easy to fix any time. No worries about TAP 1.0 vs. TAP 1.1, just download the new Test:Harness from CPAN and everything will work. Right? Regards, Jonathan Rockway
Re: Time for a Revolution
Or, perhaps we need the "Perl CPAN Cookbook" -- which would be like the Cookbook but focuses *only* on the greatest-hits modules across all the same categories. If CPAN is one of Perl's greatest strengths, shouldn't that get more attention, too? Er, right. Now let me don my editor hat. Authors welcome! A book like this is something that's been in the back of my mind for a while. If there were real interest in this topic (and I think there is), I would be happy to help out in a significant way, like writing several chapters. If someone is interested, maybe we can hash out a ToC / outline and submit a proposal to O'Reilly? That would be pretty neat :) Regards, Jonathan Rockway
Re: Fw: Fixing SKIP:
> That's incorrect, even though saying "skip X tests" reads naturally > to me. Since "skip this many for tis reason" is how I mentally think > of SKIP: blocks, I keep writing them like that, even though it's > wrong. As mentioned, it fails silently. Worse, it's inconsistent with the rest of the API: ok$foo == $bar, $REASON; is$foo, $bar, $REASON; is_deeply $foo, $bar, $REASON; And then this: skip $REASON, $num; Sadly, it would be hard to change that since so many people use the "wrong" syntax. Re-reading the man page, it looks like isa_ok and can_ok can't even accept a test description? Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
Re: Fw: Fixing SKIP:
>> Re-reading the man page, it looks like isa_ok and can_ok can't even
>> accept a test description?
>
> can_ok cannot accept a description because it accepts a list.
This could be repaired by re-prototyping can_ok as ([EMAIL PROTECTED]).
What's the reasoning behind accepting an array, anyway? Can't you just do:
can_ok($object, $_, "can object $_?") for @methods;
This would then run (scalar @methods) tests, but I'd think you'd want
that anyway. It doesn't make sense for a test for ->can("foo") to fail
when ->can("bar") fails.
Regards,
Jonathan Rockway
signature.asc
Description: OpenPGP digital signature
Re: Fw: Fixing SKIP:
> I do not think that prototype means what you think it means. It means what I think it means. Same syntax as we have currently, no. You would have to do this: my @methods = qw(foo bar baz) can_ok($object, @methods, 'reason') Instead of: can_ok($object, qw(foo bar baz), 'reason') Note that in my original post I specified "array" instead of "list" for a reason :) Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
Re: Fw: Fixing SKIP:
I retract my previous comment. My prototype was, in fact, completely bogus :) Let's make that array a reference to a list and everyone will be happy: can_ok($object, [qw(foo bar baz)], 'reason'); Hopefully that works and makes sense. If !ref $_[1], then just treat it as a single method name. Everyone's happy :) Time for sleep! Regards, Jonathan Rockway Jonathan Rockway wrote: >> I do not think that prototype means what you think it means. > > It means what I think it means. Same syntax as we have currently, no. > You would have to do this: > > my @methods = qw(foo bar baz) > can_ok($object, @methods, 'reason') > > Instead of: > > can_ok($object, qw(foo bar baz), 'reason') > > Note that in my original post I specified "array" instead of "list" for > a reason :) > > Regards, > Jonathan Rockway > signature.asc Description: OpenPGP digital signature
Re: Kwalitee metric: Broken Installer
I see two resolutions to this problem: 1) Module authors need to re-release their modules whenever Module::Install is updated. This is extremely inconvenient, but not a terrible demand. If other authors are like me, they accumulate small minor changes to their modules, and then release when something important comes along. A new M::I is "important" and would force us to keep our "stable" CPAN modules up-to-date with our svn repositories or whatever. That's a good thing ;) , but probably not the right way of going about it. (For the record, all my M::I modules use the latest version, and I went to no special effort to ensure that. So maybe this isn't as hard as it sounds.) (The right way of going about this, BTW, is out of the scope of this e-mail... but I do have some ideas...) 2) Get M::I into the core of perl, so that everyone has a known-good tested-everywhere version. This is the best idea. CPAN works so well because everyone has it and it's a good piece of software (lately CPANPLUS has gotten rather buggy and I've gone back to regular CPAN!). The other solutions (like "kwality" or whatever it's called) are stopgap measures that don't fix anything. Anyone that knows about the kwality site probably reads this list ;) and knows to update M::I anyway. The other 90% of the modules are one-offs whose authors have "better" things to do, probably, than re-release their module whenever a point release of some obscure dependency is released :). For the time being, maybe someone just needs to download the broken modules, fix the inc directory, and upload them back to the CPAN ;) That would actually solve the problem. (And introduce many others, but...) Actually now I see a third resolution: don't use M::I for CPAN modules. CPAN (the software) handles dependency installing, it's standard with perl, good enough. I do like M::I, I just can't think of why it's really necessary for CPAN modules. (For non-CPAN perl packages, though, it's a GREAT idea.) Regards, Jonathan Rockway I don't think I like it. It makes me nervous for some reason... For example, who's to say what constitutes a bad version of an installer (actually, this only applies to M::I, since the other installers aren't generally bundled, but I don't mind defending M::I here). In this case, you've declared every version prior to some arbitrary release to be bad. I doubt that is the case. I think there might have been problems with one or two releases, but being an old release is not the same as being a flawed release.
Re: Lessons from the test function parameter placement quibbles?
> I'd like test names to be more widespread, but I really don't want
> them mandatory.
If you really don't want to have test names, you can specify undef. But
making them "required" (as in "before everything else") makes the API
easier to use for people who are doing things right (i.e. naming their
tests).
use Test::More::MandatoryName tests=>3;
sub ok {
Test::More::ok(undef, @_);
}
ok($foo == $bar);
ok($baz < $quux);
can_ok('$foo loaded its methods from the XML', qw(foo bar baz can isa));
This setup is better than what Test::More does right now, since can_ok
could now accept a test name.
Regards,
Jonathan Rockway
signature.asc
Description: OpenPGP digital signature
Re: Lessons from the test function parameter placement quibbles?
This is partially true, but this is the beginning of a slippery slope down to: $i++ # increment $i by one Things like can_ok($foo, "bar") are obvious on the surface -- but it's good practice to document why you care that $foo can "bar", right? Regards, Jonathan Rockway (My mind idly wonders if it were possible to generate this test description... somehow... somewhere) -- c
Re: Real Kwalitee, or please stop spending time thinking about CPANTS
4) Adopt a Perl Mongers group. None around. Andy means adopt a PM mailing list. Mention things like the M::I issue to mongers groups that may not have anyone on perl-qa or the perl6 lists. -- Jonathan Rockway
Re: post-YAPC::Europe CPANTS news
I could be wrong here, but I think the check is to make sure that tar doesn't set +x on Makefile.PL or Build.PL, thus forcing the user to run the proper version of perl instead of automagically running the perl that shebang points to. (Example: Makefile.PL says #!/usr/bin/perl, but you really want to run /home/jon/blead/bin/perl. Forcing you to type this out is "a good thing".) I personally don't see the value of this, I always run perl Makefile.PL anyway. Do +x *.PL files cause problems with CPAN installs? (Or am I completely wrong in my interpretation of this test? :) Regards, Jonathan Rockway chromatic wrote: > On Wednesday 06 September 2006 02:53, Thomas Klausner wrote: > >> - buildtool_not_executable >> Check if the buildtool (Makefile.PL, Build.PL) are not executable >> (and thus need to be called with 'perl Build.PL' thereby specifying >> which exact version of Perl you want) > > I'm not sure of the value of this one; how does an author make the buildtool > executable on Windows, for example? I have the impression (not using > Windows) that users must always call the tool with 'perl Build.PL' on such > platforms. > > Am I mistaken? > > -- c
Re: A Suitable Iterator for TAPx::Parser
> You of course are aware of what a pain it is to apply this logic?
Yes, which is exactly why you shouldn't mess around with references
where they're not necessary. I suggest:
my $foo = Foo::Bar->new({path => $path});
or
my $foo = Foo::Bar->new({data => $data});
Foo::Bar::new looks like:
sub new {
my $class = shift;
my $args = shift; # or you could do
# eval { %args = @_ }; croak ... if $@
my $self = {};
if($args->{data}){
$self->{data} = $args->{data};
}
elsif($args->{path}){
open(my $fd, '<', $args->{path}) or die ...;
$self->{data} = do { local $/; <$fd> };
}
else {
# informative error message
die "Foo::Bar::new: blah blah blah RTFM";
}
}
--8<---
This makes it very clear exactly what is going on, and prevents any
confusion with what gets stringified where. Feel free to come up with a
better name than "data" though. (I like it, others don't.)
Regards,
Jonathan Rockway
signature.asc
Description: OpenPGP digital signature
Re: OT: cross-platform path handling
BTW, my Directory::Scratch module is meant to solve this problem. At the top of your program you: use Directory::Scratch "YourOS" and all path names passed to the module are interpreted as though they're from YourOS, even when running on some other OS. This means that you can use UNIX path names in your tests, and they'll work everywhere Path::Class does. (Of course, you can use Win32/VMS/MacOS paths, also; but UNIX is the default.) The version of D::S on CPAN right now is kind of embarrassing (got a few patches and applied them even though I felt uneasy about them), but I'll have a fixed version up tonight. So don't try the module yet -- I'll send another note to the list when I'm happy with it :) Regards, Jonathan Rockway (Disclaimer: nothing is broken in the current version, but it does assume that you're using your native OS's paths. So if you don't care about cross-platform usability, go ahead and use it now. In addition, the tests are kind of "icky", as are some of the features. YMMV. :) A. Pagaltzis wrote: > * David Golden <[EMAIL PROTECTED]> [2006-09-18 12:30]: >> Many of the test failures can be attributed to: >> >> * non-portable path expectations > > Btw, is there a chance of Path::Class becoming core? > > It is *so* *much* better than File::Find, File::Basename, > File::Spec and the rest of the entourage it’s not even funny. And > it’s also sane, as opposed to IO::All. > > Regards,
Re: OT: cross-platform path handling
I've uploaded a version that works as advertised and runs its test suite successfully on MSWin32, Cygwin, OpenBSD, and Linux. If you happen to have a more obscure OS around, I'd love to hear whether or not it works. (Of course, any other comments are also welcome!) >Directory-Scratch-0.09.tar.gz > > has entered CPAN as > > file: $CPAN/authors/id/J/JR/JROCKWAY/Directory-Scratch-0.09.tar.gz > size: 36142 bytes > md5: 7ae1eb53cbe07a6dcb2b5cba9b9c45ac Regards, Jonathan Rockway Jonathan Rockway wrote: > BTW, my Directory::Scratch module is meant to solve this problem. At > the top of your program you: > > use Directory::Scratch "YourOS" > > and all path names passed to the module are interpreted as though > they're from YourOS, even when running on some other OS. This means > that you can use UNIX path names in your tests, and they'll work > everywhere Path::Class does. (Of course, you can use Win32/VMS/MacOS > paths, also; but UNIX is the default.) > > The version of D::S on CPAN right now is kind of embarrassing (got a few > patches and applied them even though I felt uneasy about them), but I'll > have a fixed version up tonight. > > So don't try the module yet -- I'll send another note to the list when > I'm happy with it :) > > Regards, > Jonathan Rockway > > (Disclaimer: nothing is broken in the current version, but it does > assume that you're using your native OS's paths. So if you don't care > about cross-platform usability, go ahead and use it now. In addition, > the tests are kind of "icky", as are some of the features. YMMV. :) > > A. Pagaltzis wrote: > >> * David Golden <[EMAIL PROTECTED]> [2006-09-18 12:30]: >> >>> Many of the test failures can be attributed to: >>> >>> * non-portable path expectations >>> >> Btw, is there a chance of Path::Class becoming core? >> >> It is *so* *much* better than File::Find, File::Basename, >> File::Spec and the rest of the entourage it’s not even funny. And >> it’s also sane, as opposed to IO::All. >> >> Regards, >> signature.asc Description: OpenPGP digital signature
Re: Testing for test labels
> Override Test::Builder::ok to croak if it doesn't get a test name argument.
> Package that up in a module and shim it in with PERL5OPT or
> HARNESS_PERL_SWITCHES.
I kind of dislike this approach. If my tests are failing, I want them
to fail because my program is broken, not because my tests are broken.
I also don't want missing comments to stop my test from running...
sometimes you need to quickly fix something, run the tests, and *then*
make everything pretty.
So I would prefer that "t/style.t" fails due to "No description of test
on line 31 of frob.t", rather than t/frob.t failing (or croaking!) for
the same reason.
Unfortunately, this is sort of a only-perl-can-parse-Perl issue. You
don't know that you didn't have a description until you've run the test.
The best thing I can think of is to have the harness check for comments,
and report an error at the end if some were missing. Maybe it could
make up a test, so the output looks like:
-
t/real.t.ok
t/foo.t..ok
t/tap_comments...23
# FAIL: t/foo.t test #42 needs a comment
...NOT OK
Failed 1/96 tests, 98.96% okay
Failed Test Stat Wstat Total Fail List of Failed
---
tap_comments 481 23
Failed 1/1 test scripts. 1/96 subtests failed.
Files=2, Tests=96, 4 wallclock secs ( 0.11 cusr + 0.06 csys = 0.17 CPU)
Failed 1/3 test programs. 1/96 subtests failed.
-
This has the added benefit of restricting this test to the developer --
it's unlikely that end-users of your module care about the TAP comments.
I think this would be pretty easy to implement, too.
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)->config(name => do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
";$;"]->[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;->setup;
Re: Send me unusual "make" error strings for CPAN::Reporter
> Of course. Locales. It all seemed too easy.
>
> Time for plan B.
Looking for stars might be the best approach:
GNU make reports failure:
> template.l: In function `yylex':
> template.l:38: error: syntax error before '%' token
> gmake: *** [template] Error 1
BSD make errors out like this:
> template.l: In function `yylex':
> template.l:38: error: syntax error before '%' token
> *** Error code 1
>
> Stop in /home/jon/template-test (line 7 of Makefile).
Unfortunately dmake (as shipped with Strawberry perl) prints:
> dmake: Error: -- flex: No such file or directory
I don't have nmake around to see what that does...
"Error" is a common string, but only in English :/ I think the "tee"
mechanism needs to be rethought -- maybe a small wrapper around make
that gets the exit code and prints "makewrapper: *** MAKE FAILED WITH
CODE 123!"?
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)->config(name => do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
";$;"]->[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;->setup;
Re: TAP 2.0
I like the "YAML" syntax, but can we live with:
got: |
this is line 1
this is line 2
expected: |
this is line 1
this is line 2
Instead? That way a real YAML parser can parse the output of TAP, which
could be important for adoption by other languages. Rather than require
others to write a TAP parser, we can just tell them to use their YAML
parser in streaming mode. Since we aren't using *all* the features of
YAML here, we can still have a light implementation for Perl. (Not that
I'm against using a full YAML parser... but I think others are :)
> got: this is line 1
> this is line 2
> this is line 3
> expected: this is line 1
> this is line b
> this is line 3
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)->config(name => do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
";$;"]->[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;->setup;
Re: Suggestions for cpantesters
> CPAN Testers reports must be sent to the cpan-testers mailing list. As
> with
> most mailing lists, email from non-subscribed addresses is held for manual
> review.
CPAN Test reports follow a fairly rigid format that computers can easily
detect. I think it's worth auto-whitelisting messages that look like
"FAIL Foo::Bar 3.14_15" or "PASS Hello::World 2.71". The CPAN::Reporter
(?) and CPANPLUS mails look about the same, and that's the bulk of the
traffic. If you allowed those and had to moderate replies from the
author, requests for more info, etc., I think that would reduce the need
for human intervention. (Maybe you're already doing this... I don't know.)
Another idea is to have a BitCard (or something) -protected area where
you (or your software) can upload test reports on your behalf. I have
machines that I'd like to send test reports from, but don't run an MTA
(Cygwin). If I could HTTP POST the reports somewhere, that would be
good. Plus, if someone starts spamming, you can just shut off their
BitCard account.
My $0.02.
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)->config(name => do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
";$;"]->[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;->setup;
Re: Proposal for author test envvar standard (was Re: Suggestions for cpantesters)
> Personally, I use TEST_PRIVATE instead to avoid any implied ties like that.
The issue is that you don't want to run author tests for modules you
didn't write. If you're installing Catalyst to write an E-commerce
framework, you don't need to check the POD coverage on Catalyst.
However, you will want to check the POD coverage on *your* app. Hence,
you'll set PERL_AUTHORTEST_MYAPP=1 and PERL_AUTHORTEST_CATALYST=0 in
your .profile, and everything will work as expected :)
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)->config(name => do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
";$;"]->[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;->setup;
[Fwd: Re: AnnoCPAN Doc Patch Maker]
Meant to send this to the list. Sorry. Original Message References: <[EMAIL PROTECTED]> While we're on the subject... it would be nice if AnnoCPAN had a checkbox "This is a bug in the module", that (if checked) autocreated an RT ticket (in addition to posting a message) and then showed the RT ticket number near the note. I looked at the source and was going to add this myself, but I've been kinda busy. If there's interest, I'll submit a patch... (The hard part will be getting the status back from CPAN RT. I think the REST interface is turned off?) Regards, Jonathan Rockway chromatic wrote: > I read a lot of documentation for CPAN modules and find a fair few typos. > Yet > making patches for the POD is a hassle; I would have to download the archive, > uncompress it, copy the file, fix the typo, generate a patch, and submit it. > > Wouldn't it be nice to be able to pull up a text entry box online with the > contents of the POD, fix any typos inline, then submit it to the server which > can generate a patch and perhaps redirect me to rt.cpan.org? I think I'd > submit more doc patches that way.
Re: Failing test on Windows
> True. On the flip side, there's nothing more irritating that flipping
> PerlTaintCheck On only to find out a crapload of modules don't run under
> taint. And that's assuming you have control over whether the flag is set
> of not. :-/
Maybe an example would help me understand this, but doesn't the application
*itself* know how best to untaint data? If a module were to check everything
for taint, it would be roughly equivalent to $var =~ /^(.*)$/; $var = $1;
which serves no security purpose. I think that if you're running with taint
on, you (the application developer) should be responsible for properly
cleansing input. If you miss something, you'll want your app to die inside
the module so you know what your app is forgetting to check. If you don't
want your app to die, then don't use taint mode, right?
I would certainly be upset if a module, in the interest of taint safety, set
$ENV{PATH} to qw(/bin /usr/bin) when I wanted to exec a binary
in /usr/libexec/bin instead. It's up to me to know the specific details of
my environment, not a generic module.
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)->config(name => do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
";$;"]->[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;->setup;
pgpHZVXspUAm7.pgp
Description: PGP signature
Re: Sparse Test Output
> %Time ExclSec CumulS #Calls sec/call Csec/c Name
> 0.00 1.300 3.318 11 0. 0. TAPx::Parser::Streamed::_lex
> TAPx::Parser::Grammar::_make_test_token 0.00 0.889 2.277 900025
> 0. 0. TAPx::Parser::__ANON__ 0.00 0.700 0.700 11 0.
> 0. 0. TAPx::Parser::Grammar::__ANON__ 0.00 0.340 0.340 11
> 0. 0. TAPx::Parser::Grammar::_trim 0.00 0.180 0.180 20
> 14 0. 0. TAPx::Parser::Grammar::syntax_for 0.00 0.100
> 0.020 11 0. 0. TAPx::Parser::Grammar::handler_for 0.00
Looks like a lot of time is spent is spent inside the lexer / grammar engine
(and yes, my mail client messed those lines up big time. sorry), so I'm
going to play around with a flex/bison version and see if I can get a quicker
libtap going. I imagine that something like:
NOT_OK NUMBER REASON END |
NOT_OK NUMBER END{ not_ok++; }
OK NUMBER REASON END |
OK NUMBER END { ok++; }
in C should be a bit quicker than creating a perl object for each TAP line.
(Probably the Real Version would call back into the $LANGUAGE interperter, so
you can do whatever you want. If you just want counts, though, this should
be fast.)
Anyway, if anything interesting comes of this I'll let the list know.
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)->config(name => do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
";$;"]->[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;->setup;
pgpW0G7wPWFMF.pgp
Description: PGP signature
Re: Sparse Test Output
> Anyway, if anything interesting comes of this I'll let the list know.
My hunch was right -- I whipped up a quick lex/yacc parser at lunch
today, and it's about 120x faster than Test::Harness. This is just an
estimate, because Test::Harness chewed up 2G of memory while testing and
crashed. Here's the output of my informal benchmark:
[~/projects/libtap] 1 ([EMAIL PROTECTED])
$ /usr/bin/time sh -c './taptest | ./tap'
Starting...
Expected 1000 tests; 1000 passed and 0 failed.
9.89user 0.35system 0:07.14elapsed 143%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+871minor)pagefaults 0swaps
[~/projects/libtap] 1 ([EMAIL PROTECTED])
$ /usr/bin/time sh -c './taptest | prove echo.pl'
echook 8702861/1000Out of memory!
509.56user 79.17system 13:39.69elapsed 71%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (3820major+743782minor)pagefaults 0swaps
You can try for yourself with the code here:
http://trac.jrock.us/cpan_modules/browser/libtap
or
svn://svn.jrock.us/cpan_modules/libtap
(svk checkout, make tap, make taptest, and then the commands above)
Keep in mind that the code there is not a general "solves everyone's
problems" thing. It's something I hacked together in an hour :)
That said, I am willing to clean it up when I have time, and hopefully
be able to provide a libtap that makes TAP support easy for any language.
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)->config(name => do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
";$;"]->[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;->setup;
Re: Sparse Test Output
> There is already a libtap
Ah! Thanks for pointing that out. I was planning a libtap to *parse*
TAP, whereas this libtap *emits* TAP. If necessary, the name could be
changed to libparsetap or something :)
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)->config(name => do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
";$;"]->[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;->setup;
Re: CPAN.pm to install only flagged versions of modules
On Monday 30 October 2006 18:16, David Golden wrote:
> Bundle gives the option of either freezing a particular version (by
> specifying a distribution file) or else fully upgrading to the
> absolute latest version (by specifying a module).
The problem I've experienced with this method is that authors tend to delete
their modules from the CPAN (at the strong urging of messages on the PAUSE
website). This leads to broken bundles (or ports in my case), which is
mildly irritating. However, adding logic to get the files from the backpan
would eliminate this problem. (But then there's the bandwidth issue -- do we
really want automatic tools hitting the backpan?)
The other issue is of security updates. I would hate to lock people into
insecure versions of modules. Maybe there needs to be (another :) flag that
says "don't distribute this version anymore, use x.y.(z+1) instead".
Problems like this might be too late for the 5pan to solve, though. (I'm not
sure I like any of the 6pan proposals, though, so fixing the current CPAN is
not necessarily a bad idea or a waste of time.)
Regards,
Jonathan Rockway
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)->config(name => do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
";$;"]->[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;->setup;
pgp4pMn9HLdEV.pgp
Description: PGP signature
Re: The Wiki Has Been Spammed
Clint Moore wrote:
> On 12/4/06, Michael G Schwern <[EMAIL PROTECTED]> wrote:
>>
>> Thanks for reporting this, but its also nice to clean up what you
>> see. It a wiki, edit it.
>>
>
> I had that attitude once. Sort of like when I believed in Santa
> Claus. Then I decided to clean kwiki.org and rjbs's email project
> kwiki off and on for about a month. Wiki spammers can beat the
> oo-it's-a-wiki-share-contribute-learn feeling out of you surprisingly
> quickly.
I tend to password protect my wikis with a generic account like
"username foo, password bar". Won't upset any lazy humans that want to
contribute, and the spammers haven't figured it out yet. I was shocked
that my non-googlable trac site was getting problem ticket spam* within
a day or so of me launching it. Stupid, stupid spammers.
* Type: defect. Subject: ENLARGE YOUR DONG. Priority: "major".
Milestone: 1.0
They actually picked sane values for the metadata. Sad.
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)->config(name => do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
";$;"]->[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;->setup;
Re: Generating test data and testing it
Shlomi Fish wrote:
> Maybe I'm missing something, but in your second example, you declare
> $override as a lexical and don't use it anywhere. May I inquire what
> was your real intention?
I'm pretty sure he was trying to do this:
add_user.t
$testing = 1;
add_user(); # prints TAP
do_something_that_needs_a_user.t:
$testing = 0;
add_user(); # doesn't print TAP, but adds the user
ok({do_some_stuff});
The idea being that writing the add_user mech stuff twice is messy.
Suppressing the TAP seems unclean on the surface, but lacking access to
the database (so you can do a proper add_user to the data source), it
seems like a good idea to me. The code is written exactly once, and
since it's its own test, you know it works! (Self-testing code)++
--
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)->config(name => do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
";$;"]->[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;->setup;
Re: Bug fix in Test::More 0.71 may reveal failures tests
Michael G Schwern wrote:
> Test::More 0.71 fixed a subtle bug where a call to use_ok() inside a BEGIN
> block without a plan would be silently ignored. That is...
>
> use Test::More;
>
> BEGIN { use_ok('Exporter') } # for example
>
> plan tests => 1;
> pass();
>
> would pass when it should have failed. This commonly takes the form...
>
> use Test::More;
>
> if( ...something we need isn't there... ) {
> plan skip_all => "Missing something";
> }
> else {
> plan tests => 2;
> }
>
> BEGIN { use_ok('Some::Module') }
>
>
XML::LibXML does this. Attached is a patch to fix it.
Regards,
Jonathan Rockway
--- t/40reader-BROKEN.t 2007-09-15 22:31:56.0 -0500
+++ t/40reader-FIXED.t 2007-09-15 22:34:45.0 -0500
@@ -3,13 +3,15 @@
use warnings;
use Test::More;
-if (XML::LibXML::LIBXML_VERSION() >= 20621) {
- plan tests => 92;
-} else {
- plan skip_all => "Reader not supported for libxml2 <= 2.6.20";
-}
+use XML::LibXML;
BEGIN{
+ if (XML::LibXML::LIBXML_VERSION() >= 20621) {
+ plan tests => 93;
+ } else {
+ plan skip_all => "Reader not supported for libxml2 <= 2.6.20";
+ }
+
use_ok('XML::LibXML::Reader');
};
signature.asc
Description: OpenPGP digital signature
Re: Bug fix in Test::More 0.71 may reveal failures tests
Michael G Schwern wrote: > Test::More 0.71 fixed a subtle bug where a call to use_ok() inside a BEGIN > block without a plan would be silently ignored. That is... > > Found another, File::Finder. Patch to fix this is attached. Regards, Jonathan Rockway ff-useok-fix.t Description: Troff document signature.asc Description: OpenPGP digital signature
Re: Bug fix in Test::More 0.71 may reveal failures tests
A. Pagaltzis wrote: > • AIX::Perfstat (disk.t) > • Business::BR::Ids (002_cpf_test.t 015_pis_test.t) > • Cache::FastMmap (6.t) > • CGI::Application::Plugin::LogDispatch (singleton.t) > • CGI::Application::Plugin::TT (04_singleton.t) > • CGI::Uploader (up_table_map.t) > • Data::FormValidator::FromDBI (01-generator.t) > • Date::Span (from_unit.t) > • DBD::Sybase (place.t) > • DBIx::AsForm (basic.t) > • DBIx::LazyMethod (MySQL.t) > • DBIx::Simple (sqlite.t) > • DTS (AssignmentTypes.t) > • Gaim::Log::Parser (002DateTime.t) > • HTML::DBTable (02__DBSchemaPatched.t) > • HTML::TableParser (contents.t) > • Image::MetaData::JPEG (JPEG_0_records.t JPEG_1_segments.t > JPEG_2_JPEG_class.t) > • jsFind (04words.t) > • Mail::Audit (shorthand.t) > • Mail::SpamAssassin::SimpleClient (result-spam.t) > • Mail::Toaster (maillogs.t) > • Net::FTPSSL (10-complex.t) > • Oracle::Debug (oradb.t) > • POE::Component::SNMP (20_snmp_getnext.t 60_errors.t) > • Purple (api.t) > • RDF::Sesame (98-debug.t) > • sapnwrfc (06test_data_z.t 08deep_z.t) > • Search::Estraier (5_Node.t) > • Solaris::Disk::Mnttab (05half-calls.t) > • Solaris::Disk::VTOC (15size2.t) > • SVN::Notify (html.t) > • Test::MinimumVersion (pod-coverage.t) > • Text::Aspell (05-core.t) > • Text::Capitalize (003-captitle-preserve_whitespace.t) > • Tuxedo::Admin (1.t) > • WWW::Ofoto (14-upload_lots.t) > Aristotle++. Your method was much better than my "try installing stuff I need and see what fails" technique :) Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
Re: Test::Pod / YAML explodes (and taking cpants with it...)
David Cantrell wrote: > Number::Phone::UK::Data contains a big chunk of binary gibberish at > the end of the file (it's an embedded DBM::Deep database), in a > __DATA__ segment. That includes several "lines" that match /^=/ and > so might look like POD, and hence confuse things. I'd argue that this > means there's a bug in Pod::Simple::Checker and/or Test::Pod, if > they're looking at stuff in __DATA__. You might like File::ShareDir for this. That way you can keep the big data file out of band, and avoid having to maintain a database inside your perl file. Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCE] Test::Builder/More/Simple 0.72
chromatic wrote: > I have my doubts that most dev releases get *any* attention. I have had the same experience with Catalyst. We asked users for months to test the dev releases of the new Authentication architecture to make sure it was 100% backwards compatible. No reports of anything. When the stable version was released, we had people whining about breakage the very same day. *sigh* I think the problem is that 99% of Perl users don't read mailing lists. They download stuff from search.cpan (maybe), and then forget about it until something breaks. Maybe if we break stuff more often people will pay more attention? ;) Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
Module metadata
David Golden wrote: > On 9/25/07, Chris Dolan <[EMAIL PROTECTED]> wrote: > >> Well, one option might be something like: >>http://www.cpanforum.com/tags/name/helpwanted >> Gabor, would it be easy to add an Atom/RSS feed for a particular tag? >> > > Please no! Let's not spread module metadata around any more than we have to. > > Extend META.yml to include the same kind of information that used to > be managed via the modules list. If someone wants to write a website > to index and syndicate *that*, fine, but don't make authors go to > multiple places to create and manage their metadata. > Yuck. I don't want to release a new dist just to add a tag to my module. Regards, Jonathan Rockway
Re: Module metadata
David Golden wrote: > (Which reminds me to go update my module metadata on CPAN::Reporter > since I've changed license and abstract since I first registered. The > changes are in my META.yml, of course, but I forgot about PAUSE.) > This is a pretty good point and has caused me to change my mind. It would be nice to put all this stuff in META.yml. Keeping data in multiple places consistent is much more painful than uploading to the CPAN. Anyway, should the DSLIP stuff be added to the META-spec? (I see that some stuff, like the S and L parts, are already covered by META.yml. Is the rest worth adding, or is it time to forget about it?) As for "keywords", can I use those for anything? It would be nice to replace the manually-generated categories on search.cpan (and other places) with popular tags. Maybe that's too "web 2.0y" but I think it might be nice :) Regards, Jonathan Rockway
Re: Test::Load, anyone?
Ovid wrote: > Yeah, it's a crappy name. Test::Use? Test::UseOK? Test::UseAllOK, > Test::JustLoadMyFrigginPackages? : I'm fine with Test::Load. I immediately guessed what your module did by the name :) Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature
Re: get_resource_by_name() - Find full-path of something in @INC
Eric Wilhelm wrote:
> If we're voting, I would prefer to avoid having non-modules in @INC.
>
I agree. How about using Module::Install to install files to a known
location (auto), and then File::ShareDir to get at those files? I have
had pretty good success with this approach. (My CatalystX::Starter on
CPAN does this, and people don't seem to be having any problems with it.)
FWIW, Catalyst takes the approach of looking at $INC{"Your/App.pm"} to
find the path to your main application class, and then uses that path to
look for shared resources (TT templates for example). You might like
that approach best.
Full details are in &Catalyst::Util::home:
http://search.cpan.org/src/MRAMBERG/Catalyst-Runtime-5.7011/lib/Catalyst/Utils.pm
Hope this helps.
Regards,
Jonathan Rockway
signature.asc
Description: OpenPGP digital signature
Re: Deferred Plans
On Mon, 2007-11-19 at 13:06 +, Andy Armstrong wrote:
> On 19 Nov 2007, at 11:04, Ovid wrote:
> > I could get around this by loading all of the YAML files and
> > checking their count, but then I'd have to load them *again* when I
> > run the tests and that defeats the purpose of speeding up the test
> > suite.
>
>
> I think we really need to reach a decision on
>
> http://testanything.org/wiki/index.php/Test_Groups versus
> http://testanything.org/wiki/index.php/Test_Blocks
It looks like the con on both of these proposals is lack of backcompat.
My idea is to encode as much of the block information in the current
dialect of TAP as possible, and then add extra info in the comments that
new harnesses can process (and old harnesses can ignore).
How about:
# PLAN 4 BLOCKS
# {BLOCK 1} 1..2
ok 1 - BLOCK{1} TEST{1} - and the usual comment
ok 2 - BLOCK{1} TEST{2}
# {BLOCK 2} PLAN NO_PLAN
ok 3 - BLOCK{2} TEST{1}
# {BLOCK 2} 1..1
# {BLOCK 3} 1..1
...
# {BLOCK 4} 1..2
1..6
This is fully-backwards compatible with current harnesses, and even
provides most of the safety of the above proposals (a bit better than
no_plan, since the number at the bottom of the TAP is calculated based
on block declarations, not on number of tests run). Blocks can also
nest, if you want.
One thing I might add is a symbol after the # like:
#@ this is a new-style TAP command
If the @ after the # (without a space separating them) is legal in TAP
1.0, then even Test::More::diag('@ BLOCK{1} 1..2') would still be
old-style TAP as far as the new parser is concerned (since it would
print "# @ BLOCK..."). Nifty.
Thoughts?
Regards,
Jonathan Rockway
Re: New proposed CPANTS metric: prereq_matches_use
On Sun, 2007-11-18 at 18:51 -0800, Matisse Enzer wrote: > On Nov 18, 2007, at 7:25 AM, Andreas J. Koenig wrote: > >> > > Even if it's in the perl core, the developer may have compiled with > > > >-Dnoextensions=Encode > > > > In such a case Encode is not present. I have skipped Encode many times > > because it takes up so much time, others may do likewise. > > > So, I think the bottom line here is: List them ALL in Makefile.PL/ > Build.PL I've been yelled at in bug reports and on IRC for adding core modules as prereqs (think upgrading dual-life core modules on older Perl versions; I guess that's not always desirable.) I think the best solution would be something like: # Makefile.PL use 5.8.8; requires 'Encode'; # note that I'm not specifying a version; use 5.8.8 does that for me I think the real solution, though, is to agree that the perl interpreter without all of the core modules installed isn't Perl. (I'm not a big fan of core modules, but the concept is especially worthless if you can't depend on their existence.) Regards, Jonathan Rockway
Re: Deferred Plans
On Mon, 2007-11-19 at 17:08 -0600, Andy Lester wrote: > On Nov 19, 2007, at 5:04 PM, A. Pagaltzis wrote: > > > A deferred plan is clearly not as good as a predeclared plan, > > but is definitely much safer than no plan at all. > > But what if something blows up before getting to the deferred plan? > Then you don't know. You've bypassed having a plan. More information is better than less information. Consider the case where you want to run n + 10 tests. With blocks in a deferred plan, you can't be entirely sure that n is correct, but you can be sure that the other 10 tests did run. Not perfect, but better than just saying "1..63" at the end and not knowing if the "+ 10" is included in that 63. Secondly, perhaps it's possible to refactor the test to turn an entire "block" of TAP into a single test. Compare "files_are_valid(@FILES)" to "file_is_valid($_) for @FILES". Same effect, but with the first one you can declare the plan in advance. (OK, bad example because you know how many elements are in @FILES. But the concept still applies.) Regards, Jonathan Rockway
Re: Combatting attempt to censor Finance::FuturesQuote
On Tue, 2007-11-27 at 17:55 +0100, Dominique Quatravaux wrote: > > All publicly accessible BackPAN mirrors must pull this distribution > > manually, given that rsync-without-delete won't do it for you. > > Shucks! Too late. > > http://kilimandjaro.dyndns.org/~dom/FuturesQuote-0.01.pm > > Come on now. I have no idea whether that thing is any good, but these > scare tactics from The Man are just silly. Agree here. One thing to think about: is this going to get the *author* in trouble? It would be nice to change the contact information there to avoid the author being sucked into a legal battle he can't afford. He doesn't deserve legal trouble simply because he wrote a useful CPAN module that someone doesn't like... but I can't afford to defend him against a $LARGE_COMPANY. I recommend we delete the AUTHOR information and distribute this module on thepiratebay. I will definitely seed the torrent. Finally, could the C&D letter be made available? Regards, Jonathan Rockway signature.asc Description: This is a digitally signed message part
Re: BackPAN mirror owners: please delete Finance::FuturesQuote
On Tue, 2007-11-27 at 17:42 +0100, David Landgren wrote: > All publicly accessible BackPAN mirrors must pull this distribution > manually, given that rsync-without-delete won't do it for you. What legal precedent is there here? Violating the ToS is the responsibility of the user of the module, not people distributing the module. Let's not kill the free software movement by deleting anything that anyone with a lawyer requests to be deleted. Regards, Jonathan Rockway signature.asc Description: This is a digitally signed message part
Re: BackPAN mirror owners: please delete Finance::FuturesQuote
On Tue, 2007-11-27 at 09:25 -0800, chromatic wrote: > On Tuesday 27 November 2007 08:53:52 Jonathan Rockway wrote: > > > What legal precedent is there here? Violating the ToS is the > > responsibility of the user of the module, not people distributing the > > module. > > Would you also distribute a module which effectively performed a DoS against > search.cpan.org and *.perl.org? Please delete Firefox from the Internet, since users can click "reload" repeatedly and DoS a slow site. This module is just a web browser. Users are responsible for the actions of users, not the author of software that the user happens to use. BTW, I created: http://programming.reddit.com/info/61jsd/comments/ For general (snarky) discussion. This issue doesn't really concern perl-qa, since it's just going to be a big flamefest. Infecting technical mailing lists with flames and legal wanking isn't helpful to the community. My apologies for the messages so far, but this sort of thing makes my blood boil :) Regards, Jonathan Rockway signature.asc Description: This is a digitally signed message part
Re: BackPAN mirror owners: please delete Finance::FuturesQuote
On Tue, 2007-11-27 at 20:01 +0100, David Landgren wrote: > I am well aware of the futility of the quest, what with Goggle's cache > in the short term, and things like the Internet Archive and the Wayback > machine in the long term. Nevertheless we have to appear to respond > actively to something like this. Interesting point. I guess there are two schools of thought: 1) Delete it, knowing that anyone that wants it can get it. The behemoth lawyers are happy knowing that they killed the rebels, and we laugh at them because they didn't really kill anything except their own time and money.(*1) 2) Don't delete it, and defeat the lawyers in court. The end result is that everyone can get the module, and that this sort of thing doesn't happen again. I'm not really sure which school of thought I subscribe to. I will let the list decide :) (*1) Tangent 1: is is cheaper to pay a lawyer to send out C&Ds, or is it cheaper to pay a programmer to put a password / captcha on the data they don't want scraped? I would be (pleasantly) surprised if programmers are more expensive than lawyers... > PS: I kept a copy of Time::Cubic if you're interested :) :) Regards, Jonathan Rockway signature.asc Description: This is a digitally signed message part
Re: Auto: Your message 'FAIL IO-AIO-2.51 i386-freebsd-thread-multi 6.2-release' has NOT been received
On Wed, 2007-12-19 at 03:30 +, Andy Armstrong wrote: > I'm locked in correspondence with Marc now. > > His view: cpan-testers are incompetent, ego tripping, quasi-religious > nuisances. Solution: get a mail filter. If he doesn't want reports, he should devnull them. Anyway, I think most authors like the reports. Personally, it motivates me to fix my modules when I know someone is actually trying to use them. (Smokers are nice too because I can fix my modules before a real person wastes their time trying to install my broken code :) Regards, Jonathan Rockway signature.asc Description: This is a digitally signed message part
Re: is_deeply and qr// content on 5.11
On Fri, 2008-01-18 at 17:22 -0600, Jonathan Rockway wrote: > On Fri, 2008-01-18 at 16:57 -0600, Ian Malpass wrote: > > I got a failure message from CPAN testers for Pod::Extract::URI for > > 5.11.0 patch 33001 on Linux 2.6.22-3-amd64 (x86_64-linux-thread-multi-ld)[0] > > > > The failures were where I was testing to see if an arrayref of qr// > > patterns was the array I was expecting. is_deeply() has heretofore > > worked perfectly well. > > > > The test line in question is: > > > > is_deeply( $peu->stop_uris, [ qr/foo/ ] ); > > > > And the failure is: > > > > # Failed test at t/new.t line 42. > > # Structures begin differing at: > > # $got->[0] = (?i-xsm:foo) > > # $expected->[0] = (?-xism:foo) > > # Looks like you failed 1 test of 24. > > Are you positive you didn't mean to say qr/foo/i ? Are you sure that > $peu->stop_uris should be returning qr/foo/i instead of qr/foo/? Sorry to reply to myself (it's Friday, what can I say)... but under 5.8.8 and 5.10.0, this test passes: is_deeply qr/foo/i, qr/foo/ # pass Honestly, I think it's a bug in the older versions and 5.11.0 gets it right. Those two regexes aren't the same. Since there's been some discussion on p5p about regex object internals, I'll forward the message over there so they know the behavior has changed. Regards, Jonathan Rockway signature.asc Description: This is a digitally signed message part
Re: is_deeply and qr// content on 5.11
On Fri, 2008-01-18 at 16:57 -0600, Ian Malpass wrote: > I got a failure message from CPAN testers for Pod::Extract::URI for > 5.11.0 patch 33001 on Linux 2.6.22-3-amd64 (x86_64-linux-thread-multi-ld)[0] > > The failures were where I was testing to see if an arrayref of qr// > patterns was the array I was expecting. is_deeply() has heretofore > worked perfectly well. > > The test line in question is: > > is_deeply( $peu->stop_uris, [ qr/foo/ ] ); > > And the failure is: > > # Failed test at t/new.t line 42. > # Structures begin differing at: > # $got->[0] = (?i-xsm:foo) > # $expected->[0] = (?-xism:foo) > # Looks like you failed 1 test of 24. Are you positive you didn't mean to say qr/foo/i ? Are you sure that $peu->stop_uris should be returning qr/foo/i instead of qr/foo/? I know this sounds obvious... but I just want to make sure. Regards, Jonathan Rockway signature.asc Description: This is a digitally signed message part
Re: Find all the modules 'use'd in a directory
* On Thu, Feb 07 2008, Matisse Enzer wrote: > I want to utility program that I can point at a list of files and/r > directories and get back a list of all the unique modules/pragmas that > are imported via 'use' > > Before i write my own, using PPI, does this exist already in the CPAN? What's wrong with Module::ScanDeps? It has options for static scanning (regexing the code, basically) or running the code and inspecting %INC. Also, it comes with scandeps.pl, so you don't need to write any code. Regards, Jonathan Rockway
Re: Find all the modules 'use'd in a directory
* On Fri, Feb 08 2008, Dominique Quatravaux wrote: > Andy Lester wrote: > >> First, install ack, either installing App::Ack or downloading the >> standalone version from http://petdance.com/ack/ > > Interesting. Would you be so kind as to implement "grep -n"-style > output format for us Emacs users? Might as well use M-x rgrep from within emacs. Regards, Jonathan Rockway
Re: cpan-testers in the inbox
* On Mon, Feb 11 2008, Andy Lester wrote: > http://log.perl.org/2008/02/no-more-email-d.html > > Well I guess that settles that. :) This is unrelated to the usual whining about receiving FAIL reports in your inbox. Those are sent directly by the smoker, not via the cpan-testers mailing list. The cpan-testers mailing list is a mailing list that sends *every* cpan testers report; good for, say, irc bots that announce the results of testers reports live. Regards, Jonathan Rockway
Re: Idea: CPAN Category Reviews
* On Sat, Apr 05 2008, Shlomi Fish wrote: > Hi all! > > In regards to the previous discussion about trimming down CPAN and finding > better ways to find quality modules, I got an idea of making CPAN "category" > reviews. The idea was originally derived from Freshmeat.net where they often > have category reviews of the various software hosted there: > > http://themes.freshmeat.net/articles/section/category%20reviews/ > > Now I thought of importing that idea for CPAN. > > [cut] > > So what do you think - is there an interest in this? I think you should just do it. Then we can see if there is interest or not. Personally, I don't like reviews. I think reviews tend to aim for quantity over quality. For example, can you really become an expert in Template Toolkit, HTML::Mason, Template::Declare, and HTML::Template in a weekend, and then write an article? Of course not -- I use TT and TD extensively every day and I don't think I could give them a fair review. There are parts I like, but I don't think I could give you a full overview on exactly why or why not to use them. So the issue is that the reviews are very superficial unless the reviewer is an expert in all of the modules, which is rarely the case. If there are 5 similar modules, you are probably just going to pick one -- in which case, you won't be qualified to write about the other 4. So anyway, I prefer articles like "here's a cool thing I did with Foo::Bar". People can see what's good about Foo::Bar in a natural way, instead of having some review shoved down their throats. If some like Quux::Foo better, then they can write an article about that. In this system, the experts write about their areas of expertise, and let everyone else make decisions for themselves. I think that's what we need more of. As an example: http://blog.jrock.us/articles/Devel%3A%3ABeginLift.pod I suppose you could categorize that as documentation, but I like it for the "here's a module you haven't heard of before" factor. Another example: http://blog.jrock.us/articles/Adding%20more%20methods.pod The goal there was to show what you can do with Class::MOP and Moose. It's probably something you weren't looking to do, but now that you know about it, you have a new tool in your toolbox. I think that is more valuable than comparing Text::Template and TT. Anyway, no need to worry about what I think. Just add yourself to Planet Perl and start writing. Instant access to 2000+ readers. Regards, Jonathan Rockway -- print just => another => perl => hacker => if $,=$"
Re: Idea: CPAN Category Reviews
* On Sun, Apr 06 2008, Guy Hulbert wrote: > On Sun, 2008-06-04 at 23:47 +0200, Philippe Bruhat (BooK) wrote: >> > It still looks like a big job to me. >> > >> >> Kobesearch's sources are available. > > See Jonathan Rockaway's last reply in this thread. His stuff looks > really good. He pointed me to this (offlist): > > http://git.jrock.us/?p=MetaCPAN.git;a=blob_plain;f=HOWTO BTW, I meant for this to be public... but I didn't pay attention to where "Reply" sent the mail. Regards, Jonathan Rockway -- print just => another => perl => hacker => if $,=$"
Re: W3C validator without network access?
* On Sun, Apr 06 2008, Gabor Szabo wrote: > Is there a W3C validator that works locally on my computer? HTML::Tidy is close. Regards, Jonathan Rockway -- print just => another => perl => hacker => if $,=$"
Re: Munging output when running warning tests
* On Fri, May 02 2008, Eirik Berg Hanssen wrote:
> nadim khemir <[EMAIL PROTECTED]> writes:
>
>> On Friday 02 May 2008 01.24.00 Eirik Berg Hanssen wrote:
>>> use Test::More tests => 1;
>>> use Test::Trap;
>>> trap { warn "1\n2\n3" };
>>> $trap->warn_like(0, qr/1\n2\n3/);
>>
>> Ah! I like this. How did I miss this module??
>
> Perhaps I just haven't been _quite_ shameless enough plugging it? ;-)
>
>> is it possible to have trap{} return an object/sub/whatever that is created
>> by
>> the trap{}. The automagic $trap is too automagic for me.
>
> Possible? Sure, if you wrap it up for that. This is pure Perl,
> after all. :)
>
> Recommended? Not really. It kinda runs counter to the design. The
> idea was for trap{}/$trap to mimic eval{}/$@; for one thing
> list/scalar/void context is propagated into the block; for another,
> $trap is a (package, but still) global, so you may localize it.
>
> It seems to me any alternative interface will be either overly,
> un-perly verbose or else severely restricted. But, granted, the
> severely restricted interface may be enough for you.
I think the most sane interface would be:
my $trap = trap { ... };
is $trap->foo, 'foo';
is $trap->bar, 'bar';
You said you're trying to emulate $@, but $@ can be changed out from
under you rather easily, so instead of:
eval { foo() };
if($@){ error }
The defensive programmer will write:
my $result = eval { foo() };
if(!defined $result){ error } # use $@ for more details, if necessary.
This gives you more flexibility anyway:
my $a = eval { try_something };
my $b = eval { try_something_else };
if(!$a && !$b){ die 'both alternatives failed!' }
Anyway, automatically setting variables should always be avoided,
regardless of whether or not it is "perlish". I want correct tests, not
"perlish" tests.
Regards,
Jonathan Rockway
--
print just => another => perl => hacker => if $,=$"
Re: best practices for temporary files during testing
* On Sat, Jun 07 2008, David Golden wrote: > On Sat, Jun 7, 2008 at 1:58 PM, Christopher Laco <[EMAIL PROTECTED]> > wrote: >> Directory::Scratch..and it cleans up after itself. > > Module::Install-- (and a somewhat dated one, too) Module::Install with > auto_install-- Yeah, auto_install needs to die. The recently-uploaded 0.14 release kills it :) Regards, Jonathan Rockway -- print just => another => perl => hacker => if $,=$"
Re: About tidying up Kwalitee metrics
* On Sun, Jun 29 2008, chromatic wrote: > However, does making CPAN a better place require publishing a Hall of Shame > on > perl.org? > > http://cpants.perl.org/highscores/hall_of_shame Good point. The same could be said for CPAN Ratings also. Why should my module have 1 star next to it because any goof with a web browser can write a review? Why is the opinion of someone with no ties to the community considered relevant enough to show in the search.cpan search results? (The same goes for positive ratings. I've seen a lot of high ratings of modules that are rated highly for no good reason, or rated that way by its own author.) I personally don't care and generally ignore the ratings, but it's the same thing as Kwalitee, except not even objective. Regards, Jonathan Rockway -- print just => another => perl => hacker => if $,=$"
Re: CPAN Ratings and the problem of choice
* On Mon, Jun 30 2008, Greg Sabino Mullane wrote: > Why are people not rating modules, and how can we encourage people to > do so? Probably for the same reasons they don't read this mailing list, contribute to perlmonks, attend YAPC, upload their own modules, etc. I don't know exactly what this reason is, but I have a feeling it's "who cares" or "why should I bother". Regards, Jonathan Rockway -- print just => another => perl => hacker => if $,=$"
Re: Drizzle colonization
* On Fri, Jul 25 2008, Andy Lester wrote: > Drizzle is the new fork of MySQL that removes many many features to > save weight, but is still able to handle concurrent users unlike > SQLite. SQLite handles concurrent users. Some people dislike the fact that row writes lock the entire table, though. This starts being a problem when you are getting around 10-100 million writes a day, according to the SQLite docs. Regards, Jonathan Rockway -- print just => another => perl => hacker => if $,=$"
Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists
* On Sun, Sep 28 2008, Cosimo Streppone wrote: > Hi! > > I don't know if I really understand the entire > "world-writable files" security hole. > > Anyway, I think the average CPAN author doesn't > really know or care about that, sadly. > See also FWIW, this is true. I have never thought about it. Personally, I am confused as to why users have programs that do whatever an input file from the Internet tells them to do. If you don't want your tar command to create world-writable files, you should probably tell your tar command to not create world-writable files... right? That is much easier than convincing every person on the Internet to do what you want. It is also easier than convincing every CPAN author to upgrade MakeMaker. Regards, Jonathan Rockway -- print just => another => perl => hacker => if $,=$"
Re: [PATCH] ExtUtils::MakeMaker and world writable files in dists
* On Wed, Nov 12 2008, David Golden wrote: > On Wed, Nov 12, 2008 at 3:17 PM, demerphq <[EMAIL PROTECTED]> wrote: >> IMO if the toolchain is to work this should happen at PAUSE (if it can >> detect this problem IMO it should just damn well fix it itself) or at >> extraction. > > It *is* being fixed at extraction. But it requires people to upgrade > CPAN and CPANPLUS (maybe Archive::Extract as well). It was a faster > fix to close the PAUSE indexing door than to get those fixes released. I agree with demerphq here, why can't PAUSE just fix this? It won't break signatures (since they sign file content, not file metadata), and it won't break the CHECKSUMS file (since that could be generated after the tarball is fixed). It could be weird if what you upload to CPAN isn't what you download... but it fixes a security problem, and it doesn't require authors to know that this problem exists. Abstraction++ Regards, Jonathan Rockway -- print just => another => perl => hacker => if $,=$"
Re: TAP::Data or TAPx::Data?
* On Wed, Feb 11 2009, Steffen Schwigon wrote: > "TAP::DOM" is a nice idea. Thank you, too. But although DOM isn't > strictly associated to XML, most people would probably have this > connotation in mind I don't think so. Everyone calls documents-parsed-into-trees-of-objects DOMs. There is plenty of prior art on CPAN here: http://search.cpan.org/~agent/Makefile-DOM-0.004/lib/Makefile/DOM.pm http://search.cpan.org/~sprout/CSS-DOM-0.05/lib/CSS/DOM.pm http://search.cpan.org/~samv/Doc-Perlish-0.14/lib/Doc/Perlish/DOM/Node.pm http://search.cpan.org/~adamk/PPI-1.203/lib/PPI/Document.pm http://search.cpan.org/~abw/Pod-POM-0.17/lib/Pod/POM.pm At this point, I am tired of looking, but you get the idea. -- print just => another => perl => hacker => if $,=$"
Re: Testing is dead, long live Open Proofs
* On Thu, Feb 12 2009, Michael G Schwern wrote:
> chromatic wrote:
>> On Thursday 12 February 2009 14:09:41 Michael G Schwern wrote:
>>
>>> I hope somebody writes a provable kernel.
>>
>> Why? It would be practically useless unless they proved all cases of input
>> (user and hardware), in which case it would only be practically useless for
>> every case which lacks complete proofs.
>
> I'm no expert, but I'm given to understand this exactly the problem Monads
> were developed to deal with.
No, monads exist to abstract away the sequencing of computations.
In perl, we use the ";" to sequence computations, which is a function of
two arguments that executes the first argument, and then executes the
(optional) second argument. Monads generalize this concept and let you
make ";" behave differently for different types of arguments. (There
are some mechanics involved, but this is the basic idea.)
An example: http://www.haskell.org/all_about_monads/html/meet.html
mothersPaternalGrandfather :: Sheep -> Maybe Sheep
mothersPaternalGrandfather s = case (mother s) of
Nothing -> Nothing
Just m -> case (father m) of
Nothing -> Nothing
Just gf -> father gf
See the repeated "Nothing / Just" block? (Before we do the next
computation, we see if the previous on returned Nothing. If it did, we
don't do the nexe computation).
If we define a monad over the type of function that returns "Maybe"
(Nothing / Just), then we can rewrite this as:
mothersPaternalGrandfather s = do { m <- mother s; gf <- father m; father
gf }
Now the redundant check is gone. The ";" operator does it for us. (The
compiler knows that we want this behavior because `mother` and `father`
return values of the type Maybe.)
So sorry, nothing to do with proving the correctness of software. Just
another way to abstract away common code.
We don't use Monads in Perl because they only save typing if you have
type inference, and because we don't have the syntax sugar that Haskell
does. We can do the same thing in a different way. (In this case,
block eval works. If we call a method on undef, the block exits,
returning undef.)
Regards,
Jonathan Rockway
--
print just => another => perl => hacker => if $,=$"
Re: Testing is dead, long live Open Proofs
* On Thu, Feb 12 2009, chromatic wrote:
> It's trivial to write a type-safe Haskell program which does not violates
> mathematical laws tought to fifth graders and which never terminates. I can
> do it in fewer than ten lines of code.
Wait, you need ten lines for this? I would just say "print [1..]". I
hear there are a lot of integers.
The real barriers to "provably correct software" that Haskell puts up
are functions that don't work over all values of a given type ("tail
[]"), and functions that have incomplete pattern matches. (Cases that
"never happen" can happen.)
Fortunately this is easy to fix with static analysis, but it is possible
for your program to compile and start running with these errors, only to
die at an undetermined moment. That's never fun -- so testing is needed
even in Haskell programs.
Regards,
Jonathan Rockway
--
print just => another => perl => hacker => if $,=$"
Re: Stupid prove tricks
* On Wed, Feb 25 2009, Michael G Schwern wrote: > Here's a kind of crappy way to make TAP read from STDIN. > > $ prove --exec 'cat -' test.dummy > test > > Now you can write TAP and finish with ctrl-d. But test.dummy has to exist. I just tried this, and it works without test.dummy existing (although it complains after you type the TAP). This doesn't happen if you use /dev/null, though (as in prove --exec 'cat -' /dev/null). -- print just => another => perl => hacker => if $,=$"
Re: Test::More::does_ok()
* On Wed, Apr 08 2009, Michael G Schwern wrote:
> # Moose
> sub DOES {
> return $_[0]->meta->does_role($_[1]);
> }
>
> # Class::Trait
> sub DOES {
> return $_[0]->does($_[1]);
> }
Why is the Perl 5.10 way ALL CAPS, anyway? DOES is not automatically
called by Perl, is it? (Follow-up question: why is isa not ISA?)
--
print just => another => perl => hacker => if $,=$"
Re: Making TODO Tests Fail
* On Mon, Jul 13 2009, Ovid wrote: > How would Smolder (which we're not using since we use Hudson) help > with this? With over 15,000 tests being reported for t/aggregate.t, I > think a drill-down would be problematic here. Plus, tying the TODO to > the appropriate test file being aggregated is needed. Thus, I thought > about a BAILOUT or forced failure for the TODO at that point. Can't you just put the TAP into a database, and do a quick query to extract the file, test number, and line of passing TODO tests? Surely some code might need to be written, but it doesn't sound too hard. -- print just => another => perl => hacker => if $,=$"
Re: Discourage use_ok?
* On Mon, Nov 09 2009, David Cantrell wrote: > On Mon, Nov 09, 2009 at 11:41:21AM +0100, Philippe Bruhat (BooK) wrote: >> On Mon, Nov 09, 2009 at 02:24:11AM -0800, Ovid wrote: >> > Thinking about this more, what about a compile_ok()? >> compile_ok() would certainly be interesting with scripts shipped with >> a module, that usually have very little meat that needs testing (since >> most of the work is done in the modules), but that one would at least >> check that they compile. > > Why not test that the script *works*, not just that it compiles? Why use a script at all? They are clearly difficult to test, and code that is difficult to test is where the bugs always hide. (Yeah, this is a bit of an old thread, but I am behind on my mailing list mail :) Regards, Jonathan Rockway -- print just => another => perl => hacker => if $,=$"
