Re: Starting with a fresh sandbox
> One simple way around this is to use SelfTest or Test::Inline and
> throw in at the top of each of your modules:
>
> =for testing
> use_ok('My::Self');
>
> and then just run the tests in each self-testing module in turn.
The bummer is that I'm not the only programmer, and I've had problems with
..pm files being created that don't compile on their own. I want an
automated test to File::Find thru the source tree and load up each .pm as
it gets found, making sure it'll load on its own. As it stands now, I DO
have a test that makes sure each .pm has a corresponding .t, but of course
I can't guarantee that the .t is even useful.
xoxo,
Andy
--
'Andy Lester[EMAIL PROTECTED]
Programmer/author petdance.com
Daddy parsley.org/quinn Jk'=~/.+/s;print((split//,$&)
[unpack'C*',"n2]3%+>\"34.'%&.'^%4+!o.'"])
Starting with a fresh sandbox
I'm using Test::More for doing infrastructure testing throughout my
project. One of the tests I'm doing is making sure that every .pm file is
able to load on its own, since I've had problems where the .pm had
dependencies on other modules, but so long as the calling program included
those modules first, the problem would remain hidden.
So I have a test where I do a use_ok( 'Foo::Bar' ). All fine and good.
What I'd like is a way to do use_ok( 'Foo' ) and a use_ok( 'Bar' ), but
somehow make sure that the order of checking these not matter. Even in an
eval {}, my namespace is going to be polluted after the first use_ok(),
sin't it?
Thanks,
Andy
--
'Andy Lester[EMAIL PROTECTED]
Programmer/author petdance.com
Daddy parsley.org/quinn Jk'=~/.+/s;print((split//,$&)
[unpack'C*',"n2]3%+>\"34.'%&.'^%4+!o.'"])
Re: Starting with a fresh sandbox
> Teach the other folks how to test. :)
The journey of a thousand miles begins with a single step, and in this
case the single step is making it terribly obvious to me as the lead tech
that their code doesn't compile properly. :-)
> sub test {
> return unless /\.pm$/;
> print "# compiling $_\n";
> system(qq{$^X -e 'print eval { require "$_"; 1 } ? "ok\n" : "not ok\n"' });
> }
>
> adjust as necessary. Doesn't have to be fancy.
Actually, it's going to have to be fancy, but that's my bummer, not yours.
This method works well for about 2/3rds of the modules.
Thanks for th input.
xoxo,
Andy
--
'Andy Lester[EMAIL PROTECTED]
Programmer/author petdance.com
Daddy parsley.org/quinn Jk'=~/.+/s;print((split//,$&)
[unpack'C*',"n2]3%+>\"34.'%&.'^%4+!o.'"])
Re: Pondering Test::Depend
> I'm a big fan of testing units in isolation. It's easier, faster, and tends to > more comprehensive and detailed tests. The problem is, if the unit being > tested has a legitimate dependency on another unit in the suite, isolation > testing cannot identify interface changes. I've been vaguely reading the Schwernomatic commentary, and most of it doesn't interest me directly. I'm not enough of a module-writin' guy to see how it's gonna help me at all. Here are my two concerns: * Please don't make dependencies on *.t as the filenames involved. I'm personally using Test::Harness to run tests on other files as well. * Dependencies should be optionally based on something other than just the timestamp of a file. For instance, I suspect I'd like to be able to make the date dependency on "SELECT MAX(DateUpdated) FROM Foo". xoxo, Andy -- 'Andy Lester[EMAIL PROTECTED] Programmer/author petdance.com Daddy parsley.org/quinn Jk'=~/.+/s;print((split//,$&) [unpack'C*',"n2]3%+>\"34.'%&.'^%4+!o.'"])
use_ok w/version numbers
I can do this: use PHP::Session 0.10; to ensure a version number, but I can't do this: use_ok( 'PHP::Session', '0.10' ); because I get this error: alester@flr4[~/tw/Dev]$ more Modules.t #!/usr/bin/perl -w use strict; use Test::More tests => 1; use_ok( 'PHP::Session', '0.10' ); alester@flr4[~/tw/Dev]$ perl Modules.t 1..1 not ok 1 - use PHP::Session; # Failed test (Modules.t at line 6) # Tried to use 'PHP::Session'. # Error: Can't locate object method "require_version" via package "PHP::Session" (perhaps you forgot to load "PHP::Session"?) at /usr/local/lib/perl5/5.6.1/Exporter/Heavy.pm line 105. # Looks like you failed 1 tests of 1. Before I go digging into a patch, is this something that we even want to allow? I know I'd like to allow it, because I'd like to have one .t file that ensures that I have proper module prereqs for my entire source tree. xoxo, Andy -- 'Andy Lester[EMAIL PROTECTED] Programmer/author petdance.com Daddy parsley.org/quinn Jk'=~/.+/s;print((split//,$&) [unpack'C*',"n2]3%+>\"34.'%&.'^%4+!o.'"])
Re: [PATCH Test::More] Allow isa_ok( $classname, $parent )
> The purpose of isa_ok() is two fold:
>
> Check that a scalar contains an object
> Check that object is of the right class
I've recently started using it for more than constructors. Here's a
patch to the docs to encourage this:
Thanks,
xoxo,
Andy
--- More.pm Sat Jul 6 22:57:13 2002
+++ More-new.pm Sat Jul 6 23:06:44 2002
@@ -510,6 +510,25 @@
you'd like them to be more specific, you can supply an $object_name
(for example 'Test customer').
+isa_ok can be used for any place where you want to check a function's
+return value. For example:
+
+my $file = new Foo::File( $filename );
+isa_ok( $file, 'Foo::File', "Opened $filename" );
+
+my $record = $file->next_record();
+isa_ok( $record, 'Foo::Record', "Read a record" );
+
+You don't think of next_record() as a constructor, but you still want to
+ensure that the correct value is being returned.
+
+And of course, you don't have to test only your code. The more tests you
+write, the more stringent your checking:
+
+# From a DBI program
+my $row = $dbh->fetch;
+isa_ok( $row, 'ARRAY', "Got row from DB" );
+
=cut
sub isa_ok ($$;$) {
--
'Andy Lester[EMAIL PROTECTED]
Programmer/author petdance.com
Daddy parsley.org/quinn Jk'=~/.+/s;print((split//,$&)
[unpack'C*',"n2]3%+>\"34.'%&.'^%4+!o.'"])
Testing failure in Test::Builder-based modules
I'm adding some tests to Test::HTML::Lint, and one of the things that I
want to check for is that "html_ok(undef)" fails. Remember that
html_ok() is a T::B-based module.
The best I've got so far is this:
--cut--
use Test::More tests => 4;
use Test::HTML::Lint;
BEGIN { use_ok( 'Test::HTML::Lint' ); }
my $chunk = "This is a fine chunk of code";
TODO: { # undef should fail
local $TODO = "This test should NOT succeed";
html_ok( undef );
}
html_ok( '' ); # Blank is OK
html_ok( $chunk );
--cut--
I see two problems with this approach:
* It's not really a TODO item.
* If html_ok(undef) unexpectedly succeeds, the results aren't really
obvious:
t/00.load...ok
t/01.coverage...ok
t/10.test-html-lint.ok
1/4 unexpectedly succeeded
t/11.test-html-lint-overloadok
In this case, "unexpectedly succeeded" really means "html_ok is broken".
:-(
Thoughts?
Thanks,
xoxo,
Andy
--
'Andy Lester[EMAIL PROTECTED]
Programmer/author petdance.com
Daddy parsley.org/quinn Jk'=~/.+/s;print((split//,$&)
[unpack'C*',"n2]3%+>\"34.'%&.'^%4+!o.'"])
Re: Web Site Testing
> 4) WWW::Automate and WWW::Chat I've forked WWW::Automate as WWW::Mechanize, to make it a bit more robust, and to fix the bugs that have gone unfixed for at least six months. Also, I don't see any mention of content handling. My HTML::Lint and its Test::HTML::Lint wrapper check the structure of the HTML in a page. Also, Max Maischien's newly-released Test::HTML::Content allows for tests on the contents of the file, with things like "do we have a link to X", "do we have any comments on the page?" and so on. http://search.cpan.org/dist/Test-HTML-Content/ xoxo, Andy -- 'Andy Lester[EMAIL PROTECTED] Programmer/author petdance.com Daddy parsley.org/quinn Jk'=~/.+/s;print((split//,$&) [unpack'C*',"n2]3%+>\"34.'%&.'^%4+!o.'"])
Test::Pod 0.95 is out
There's a new Test::Pod in town, and it uses Sean's Pod::Simple instead of Pod::Checker. Details at http://use.perl.org/~petdance/journal/10867 Comments welcome, of course. xoxo, Andy -- Andy Lester, lead singer & driver of the Winnebago [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
Re: Test::Pod 0.95 is out
Not sure how I feel about this. If you were still using Pod::Checker, I'd definately say it won't fly since it throws so many silly warnings. You mentioned a few, the "Empty Paragraph" and that you can't use "=item foo" more than once. Pod::Simple is hopefully more realistic. Right, it's the silly warnings that I'm most concerned about getting rid of. Pod::Simple is indeed more realistic. xoa -- Andy Lester, lead singer & driver of the Winnebago [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
Re: WWW::Mechanize 0.37 released
Damn. I still forgot to check out this incredible cool sounding module, I have some HTML-output testing in a testsuite and it is very whacky and uncomplete... I'd be glad to look at it, and see what kinds of things Mechanize can do. xoa -- Andy Lester, lead singer & driver of the Winnebago [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
Re: WWW::Mechanize 0.37 released
You could allow the user to choose between internal and external tests, where the internal tests are much simpler, maybe including a trivial self-contained webserver to make sure everything works. Help me out here. I'm trying to imagine why someone would want WWW::Mechanize without a net connection. Or are you saying that people will want to use it strictly behind a restrictive firewall where google.com isn't accessible? xoa -- Andy Lester, lead singer & driver of the Winnebago [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
Re: WWW::Mechanize 0.37 released
I installed it on a machine at work, and a large number of tests failed because the machine has no access to the outside world. Fixing that is probably more effort than it is worth, but you might want to keep it in mind for the next major rewrite. There really aren't many tests that are meaningful without that access. 00.load.t, 99.pod and add_header.t are all that seem to be valid without it. xoa -- Andy Lester, lead singer & driver of the Winnebago [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
Re: WWW::Mechanize 0.37 released
For example, we use it at work for testing our web applications. The slightly overly-secure server we use for developing can not see the Internet, but it can test on localhost or other internal servers. (There's a local CPAN mirror and other such things to make it bearable). I've created RT ticket #2185. If anyone would like to implement this and submit the patch to me, I'd appreciate it. I'm fresh out of tuits for implementing daemons on the fly. xoa -- Andy Lester, lead singer & driver of the Winnebago [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
Re: [PATCH] Test::Pod pod_ok( $foo, NO_POD | POD_OK ) also dogfood.t
if( has_pod( $file ) ) {
pod_ok($file, POD_OK);
}
Test::Pod is getting rewritten to use Pod::Simple instead of
Pod::Checker. All the "mode" flags that are passed to pod_ok() will be
deprecated. Also, pod_ok() itself will be deprecated, in favor of
pod_file_ok() and pod_string_ok().
But the dogfood is a good idea.
xoa
-
Andy Lester, lead singer & driver of the Winnebago
[EMAIL PROTECTED], AIM:petdance
http://petdance.com/ http://use.perl.org/~petdance/
WWW::Mechanize 0.37 released
There's a new version of WWW::Mechanize for you people who do automated testing with it. It adds a title() and is_html() method, and removes the dependency on Clone, which I hope will fix stability issues on Windows. xoa -- Andy Lester, lead singer & driver of the Winnebago [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
Test::Harness 2.27_01 released
At Schwern's request, I've uploaded a beta of Test::Harness 2.27. Changes are all his. This is a transitional release before I start doing actual new code in it. Hugo/Jarkko: Please let me know what I need to get to you to incorporate these? Diff against bleadperl, of course, but do you take everything? 2.27 Sun Sat 23 21:12:00 EDT 2003 - Fixed when the path to perl contains spaces on Windows * Stas Bekman noticed that tests with no output at all were interpreted as passing - MacPerl test tweak for busted exit codes (bleadperl 17345) - Abigail and Nick Clark both hit the 10 "huge test that will suck up all your memory" limit with legit tests. Made the check smarter to allow large, planned tests to work. - Partial fix of stats display when a test fails only because there's too many tests. - Made wait.ph and WCOREDUMP anti-vommit protection more robust in cases where wait.ph loads but WCOREDUMP() pukes when run. - Added a LICENSE. - Ilya noticed the per test skip reason was accumlating between tests. xoa -- 'Andy Lester[EMAIL PROTECTED] Programmer/author petdance.com Daddy parsley.org/quinn Jk'=~/.+/s;print((split//,$&) [unpack'C*',"n2]3%+>\"34.'%&.'^%4+!o.'"])
Test::Harness 2.27_01 released
At Schwern's request, I've uploaded a beta of Test::Harness 2.27. Changes are all his. This is a transitional release before I start doing actual new code in it. Hugo/Jarkko: Please let me know what I need to get to you to incorporate these? Diff against bleadperl, of course, but do you take everything? 2.27 Sun Sat 23 21:12:00 EDT 2003 - Fixed when the path to perl contains spaces on Windows * Stas Bekman noticed that tests with no output at all were interpreted as passing - MacPerl test tweak for busted exit codes (bleadperl 17345) - Abigail and Nick Clark both hit the 10 "huge test that will suck up all your memory" limit with legit tests. Made the check smarter to allow large, planned tests to work. - Partial fix of stats display when a test fails only because there's too many tests. - Made wait.ph and WCOREDUMP anti-vommit protection more robust in cases where wait.ph loads but WCOREDUMP() pukes when run. - Added a LICENSE. - Ilya noticed the per test skip reason was accumlating between tests. xoa -- Andy Lester [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
Re: Using environment variables to control long running tests
You beat me to it, but I think PERL_SMOKE would be better. The automated tools that need to run the long tests instead of the short tests are the "smokers". Except that "smoke" has the context of the perl distro tests that are getting done. If anybody's gonna be using the "smoke" concept, it'll be me naming the command-line wrapper around Test::Harness... xoxo, Andy
Re: Test-first development
> > http://tejasconsulting.com/articles/test-first.html > > There's an article by some bloke about test driven development in this > month's Perl Journal. AND there's one lined up for the upcoming issue of The Perl Review! -- 'Andy Lester[EMAIL PROTECTED] Programmer/author petdance.com Daddy parsley.org/quinn Jk'=~/.+/s;print((split//,$&) [unpack'C*',"n2]3%+>\"34.'%&.'^%4+!o.'"])
Re: Test::Deep namespace
It's a Test::Builder based testing module, it's designed to replace and enhances Test::More's is_deeply() and eq_set(). is_deeply() has several limitiations like not handling circular references and ignoring the blessedness of references, it also has a few bugs. It would be nice if the functions ended in _ok, so it's clear that they are actually outputting and not just returning booleans. I think that Test::Data might be a better place for them, somehow. I'm maintaining brian d foy's Test::Data:: hierarchy, so maybe we can figure something out. Andy
Re: [ANNOUNCE] Test::Warn::None 0.02
All this "make sure no warnings fired" is good thinking. But why not roll it into Test::Harness, and make it switch selectable? It's really T::H that we want keeping an eye on this, right? xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: blocks and subplans again
Why would you want to do this? Simple example. This is something Schwern and I have discussed before, and that I would LOVE to put into Test::Harness, if only we could hash out the specifics. Are you ever in AIM/IRC? I'd kinda like to have an online workgroup to thrash on the specifics... xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Updates to qa.perl.org
There are a couple of minor tweaks to qa.perl.org. Soon, I'll have a page up for the Phalanx project and THEN we'll have ourselves a good time! xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Phalanx and testing distributions
Some of this distribution testing could likely get incorporated into the Phalanx project, if I get it announced today like I'd like to do... Phalanx = "beefing up test suites of Perl and the top 100 CPAN modules to make a good test bed for Ponie" xoxo, Andy -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Phalanx has started, and I need perl-qa's help
The Phalanx project has started its rampup to an official announcement. Phalanx is going to beef up the tests, coverage and docs on Perl and 100 heavily-used modules from CPAN. The project page is at http://qa.perl.org/phalanx/. Please take a look, tell me your thoughts, and if there are any serious ommissions from the Phalanx 100 module list... I'm turning to the perl-qa group for feedback BEFORE I announce to the world, so I appreciate any comments. Thanks, xoxo, Andy -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Phalanx has started, and I need perl-qa's help
I'll be interested to see how you handle non-Perl dependencies as in C libraries. Yeah, me too! :-) If we do, then it won't be the Phalanx 100 anymore, will it. :) I'd highly recommend against a naming scheme that limits your implementation. Hard coded constants and all that. :) How does it limit my implementation? Do you know for a fact that there are exactly 100 modules in the Phalanx 100? At one point, the count was 103, and that was fine by me. :-) I'd also recommend you list by Module::Name rather than Distribution-Name. If nothing else the Module::Name is more consistent. The basic work unit of Phalanx is going to be the distribution. A team will take a distribution and work on it. Now, I may expand the list to show the modules that are in the distribution, but I'm looking at this from the point of view of organizing the effort. Here's some Really Important modules you're missing. I'm using http://mungus.schwern.org/~schwern/cgi-bin/perl-qa-wiki.cgi?EssentialModules for reference. It looks like you've left off all CPAN modules which are also in the core, I suppose you're figuring they'll be handled by the core smokers. Core modules are phase two because of the Extra Excitement that will be caused by mucking with them and pumpking coordination and whatnot. Most I mention because they're important. Some I mention because they tend to break a lot and reveal subtle incompatibilities in Perl. Thanks for the list. xoxo, Andy -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Announcing the Phalanx project
Phalanx is a Perl QA project created to provide a solid testing base for Ponie, the next version of Perl 5 that will be based on the Parrot virtual machine. By increasing the test coverage of Perl modules and Perl itself, we will make Ponie be the best-tested version of Perl ever. We also hope to involve members of the Perl community who might not have contributed to Perl before. The first phase of Phalanx will update the tests in 100 of the most-widely modules on CPAN. A Phalanx team member, or hoplite, will pick a distribution and, with the agreement and cooperation of the module's author, start working on the improvements. There may be one hoplite, or many, if the lead hoplite wants to bring others into her part of the project. Along the way, the hoplites will verify accuracy of the documentation, explore the depth and breadth of the module, and make sure that everything that can be tested is tested. Once changes are made, the lead hoplite will feed her patches back to the author, who will update his distribution. All changes are voluntary, and the author still retains full control of his module. There are three goals for Phalanx. The first is to provide an excellent set of tests for the next version of Perl. Perhaps even more important, we want to encourage participation from members of the community who have never contributed back to Perl. It will be easy to get involved, and your involvement can be as much or as little as necessary. Prospective hoplites need not be part of perl5-porters or any perceived "Perl cabal", or even know about Perl internals. Finally, we're certain that we will uncover undiscovered bugs, and we'll identify them for the author, if not eliminate them. We hope that module authors will welcome the contributions of the community, and that those who are interested in getting involved with Perl and open source can make a contribution, no matter how small. Even one .t file for a distribution, or updated documentation for a function, can be a big help. After we've had some success in the first phase of Phalanx, we'll expand the process to Perl 5 itself and the core modules. This phase will be trickier, as we must work with the pumpkings and the rest of perl5-porters. We hope to have enough good lessons learned that it will be an easy transition. Please visit the Phalanx website at http://qa.perl.org/phalanx/. If you'd like to help out, join the perl-qa mailing list, or email me at [EMAIL PROTECTED] I look forward to hearing from you. -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Phalanx site updates
I've updated http://qa.perl.org/phalanx/. I started a roster page and a status, which shows that Shawn Carroll has started working on Date::Calc. Shawn, please let me know how many tests were in Date::Calc before you started. One of the metrics I want to keep is how many tests we've added as we go along. Jay Flowers has started working on CGI::Application, I believe. Jay, I'll need to know the Before stats on it. The CMS on perl.org makes updates really simple, so please let me know what's going on and I'll updated fairly often. Thanks, xoxo, Andy -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
We're up to 5 hoplites
We now have 5 distributions currently being worked on in the Phalanx project. See http://qa.perl.org/phalanx/status.html for details. Come join the fun! Pick a module and let me know about it! xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: problem with a test exemple on the Phalanx web site
At 1:01 PM -0400 10/4/03, Dominic Letarte wrote: on the page : http://qa.perl.org/phalanx/kwalitee.html ok( unlink $filename, "Remove $filename" ); should be written: ok( unlink( $filename), "Remove $filename" ); unless you want Perl to take "Remove $filename" as an arg for unlink and not for ok. Thanks. I rewrote it as is( unlink($filename), 1, "Remove $filename" ); Better to test for exactness than truth. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Testers & PASS
> Secondly, who do I need to convince to add the "make test" results for PASSes too? ;-) Perhaps Adam J. Foxson. He maintains "Test::Reporter", which makes it very easy to submit testing results through the 'cpantest' binary. His address is: [EMAIL PROTECTED] Please include me on those, as I'm updating Test::Reporter as my module on Phalanx. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Phalanx updates
We've got a couple new hoplites out there, so check out the status page. http://qa.perl.org/phalanx/status.html Also, Paul Johnson has some slick stuff on CPAN module coverage that should be interesting for new hoplites to take a look at, to see which modules are covered least. Percentage aside, I was amazed that Damian's Parse::RecDescent only has 18 tests. Not files, tests. Thanks to Dominic Letarte to working on it. I'd like it if y'all could give us some idea on how things are progressing. I'd start with a status report on my work with Test::Reporter, but I haven't done anything yet, other than suck it into my CVS. How are the rest of you doing? Thanks, xoxo, Andy -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Devel::Cover and large test suites
> Devel::Cover issues aside, has anyone else looked at interesting ways of > making test suites run faster? One of the drums I beat heavily in my discussion of testing of large projects is that you shouldn't care how long your tests take, so long as they run within the smokebot window. The way we do it is having an hourly cron job that checks out the main CVS project and runs a full blown make test on it. This means that we don't get immediate feedback if a check-in causes a failure, but getting feedback within 59 minutes is close enough to immediate for me. Also, smokebot failures are mailed to the entire department (8 people), so that helps raise the visibility. We've also had to have a 2nd smokebot running, this time hourly on the half hour, to check out and smoke the branch for the parallel project we're running. Also, as an FYI, one of the things I'm going to be adding to Test::Harness soon (Where are those tuits?) is the ability to run the .t files in random order, in the hopes of exciting bugs that are for some reason dependent on order of execution. xoxo, Andy -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Devel::Cover and large test suites
> Theres something of a nascent convention here; > 00_*.t and 99_*.t could be 'reserved' to be 1st and last > respectively, with others randomized. That's pretty much what I was thinking about doing. [0-4]*.t = startup, in that order, and [5-9]*.t = shutdown, in that order. The rest are shuffled. But nothing definite yet. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Trying to spear a phalanx shield for pod
> Is it worth trying to agree on a de facto standard name for > such a beast: 99-pod.t/99_pod.t/99.pod.t/99pod.t? Personally, I'd just as soon not have it be one of the numeric ones. It doesn't matter what order it's run in. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Phalanx updates
On Tue, Oct 28, 2003 at 11:24:51AM +, Tim Bunce ([EMAIL PROTECTED]) wrote: > I'd be very happy if you could find someone willing to rework, > and ideally then extend, the DBI test suite. Parts of it date back > to before perl 5.0 was released :) That is indeed a goal. We're holding off on the biggies (the modules in the top two sections of the list) until we've had some success with the other 70. I definitely want all 30 of the top 30 covered. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Phalanx
1) DBI (Tim Bunce specifically asked for help in re-designing the test suite). 2) CPANPLUS. 3) Module::Build. I'm all for having those biggies handled by Phalanx, and handled well. That's why I'd like to hold off on the top two tiers at http://qa.perl.org/phalanx/distros.html until we get some successes on smaller modules, and some lessons learned from them. xoa -- Andy Lester [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
Re: Phalanx
While Andy would certainly be the best person to answer this, I rather like the idea of an entire Perl Mongers group becoming a hoplite. I can't help but wonder if a little friendly competition amongst groups might be a wonderful thing. Who can get the most modules tested? I agree entirely. When I came back from OSCON I was awed by how much raw Perl power is in London.pm, and how much they drive the Perl community, especially on Perl 6. I came back to Chicago.pm and challenged them to do something similar with Phalanx. xoa -- Andy Lester [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
Hoplites report!
So does anyone have anything to report as far as progress on their modules? Reports back to update on the website would be appreciated. Note that all the status pages, like http://qa.perl.org/phalanx/status/Archive-Tar.html are actually POD behind the scenes, so if Andrew wanted to update http://qa.perl.org/phalanx/status/Archive-Tar.pod and mail it back to me, that would be fine. Thanks, xoa -- Andy Lester [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
Re: Hoplites report!
I got no response from the author. In worst case, I plan to post the tests files on rt.cpan.org. I'm sure Damian will be fine with it. I told him about the project a while ago and he seemed genuinely excited about it. xoa - Andy Lester [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
Re: reducing size of the Devel::Cover html report
I've added functionality to strip POD entirely and to stub blank lines. I've also gutted the implementation trying to save characters (literally, individual characters) wherever possible. I've got it down to 342 kB. There isn't much more room to squeeze stuff out. Personally, I find the POD useful when I'm going thru a Devel::Cover run. I interleave POD with functions and I like to refer to my docs. xoa -- Andy Lester [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
Hoplites: Watch for "each"
Anything that uses the C operator is a prime candidate for bugginess. Please keep an eye out for them as you do your testing. Any function that contains C oughta be heavily checked. Ditto anything that uses C or C without a sort. xoa -- Andy Lester [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
Test::Harness 2.31_02: Now with prove (nee grind)
I just put out Test-Harness-2.31_02.tar.gz. Please download and start beating on it. I'm especially interested in people using the new F utility. It's for testing .t files without having to run make test, as in: prove t/*.t or just prove t/ or prove -v -b -r t/ # -v =verbose, -b=use blib, -r=-recursive Many fun things to do, geared towards making the cycle of code/test a shorter one... xoa -- Andy Lester [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
Re: Hoplites: Watch for "each"
Anything that uses the C operator is a prime candidate for
bugginess. Please keep an eye out for them as you do your testing.
Any function that contains C oughta be heavily checked.
Ditto anything that uses C or C without a sort.
Elaborating: Code that uses C, C or C may have
worked in the past because the order of elements would be the same
between runs. For instance, you have one hash, and then another hash
with the same keys, and the code relies on those keys being in the same
order between the hashes. This reliance might be explicit or
accidental. Now, with 5.8.1 randomizing hashes, that code may break.
Also, in .t files, it'd be a good thing to not rely on each/keys/values
when determining the order of tests, because subsequent test runs might
not be in the same order. For example:
my %tests = ( test1 => 'foo', test2 => 'bar', etc );
while ( my($key,$val) = each %tests ) {
# do a test
}
The order in which these tests are done will be different between runs
of the code...
xoa
--
Andy Lester
[EMAIL PROTECTED], AIM:petdance
http://petdance.com/ http://use.perl.org/~petdance/
Re: Hoplites: Watch for "each"
But rather than post emails with such guidelines, only for them to be lost in the sands of time, wouldn't it be better to update the web site? Yeah, it would. I'd like to come up with a list of guidelines of things to watch for. Lately, I've been spending my free time on prove and Test::Harness. xoa -- Andy Lester [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
Re: reducing size of the Devel::Cover html report
Personally, I find the POD useful when I'm going thru a Devel::Cover run. I interleave POD with functions and I like to refer to my docs. Well, since POD is intended to be documentation (not code or even comments) it seems reasonable to omit it from a coverage report. That said, if I can find a clean way to make it an option, I'll do so. If I've got docs for a function, then I want to see them while I'm considering the code. Code and documentation are, especially w/POD, interconnected. That's the beautiful thing about POD. -- Andy Lester [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
Re: tesing exceptions of Error.pm
How am I going to test this ? Take a look at Test::Warn for warnings, and Test::Exception for errors. I think qa.perl.org needs a listing of Test::* modules so that people know what's available. xoa -- Andy Lester [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
Re: tesing exceptions of Error.pm
lists many of them, but maybe a more comprehensive list would categorize them in 'test modules that use the Test::Builder framework', 'test report utils' (such as Test::Harness), 'mod_perl related tests', etc. Iain Truskett and I are working on such a list right now. Actually, he's done working, but I have to finish my part. xoa -- Andy Lester [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
Re: T::H 2.38
prove begins with #!/usr/bin/perl and prove-switches.t runs it with my @actual = qx/$prove -Ifirst -D -I second -Ithird -Tvdb/; A $^X should be inserted here. (in bleadperl, the shebang line of prove is fixed when installed.) What should be in prove's shebang? xoa -- Andy Lester [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
Re: T::H 2.38
my @actual = qx/$prove -Ifirst -D -I second -Ithird -Tvdb/;
A $^X should be inserted here.
(in bleadperl, the shebang line of prove is fixed when installed.)
What should be in prove's shebang?
The $Config{startperl} configure variable of the perl being installed.
How can I get that in there? Or are you saying I should run it as
my @actual = qx/$Config{startperl} $prove -Ifirst /;
xoa
--
Andy Lester
[EMAIL PROTECTED], AIM:petdance
http://petdance.com/ http://use.perl.org/~petdance/
Re: bug? in Test::More error counting ? MINIMIZED TEST CASE
> It appears that this doesnt error on 5.8.2, but is repeatable on 5.00503, > as follows: I don't see any problem here. You can't have more than one plan. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: "Default" test name?
> However, I was wondering if anybody else ever wanted to do this sort of > thing and, if so, would a more generic API to the test name be useful - > e.g. localising something like $Test::Builder::Test_name? I say leave it up to the individual *_ok sub. use_ok() already supplies the name itself, and all of my Test::* modules create their own test name if there's not one passed. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: ok(1,1) vs. ok ('foo','foo') in Test::More
On Tue, Feb 03, 2004 at 06:44:04PM +0100, Tels ([EMAIL PROTECTED]) wrote: > is there a re reason that the following warns: > > % perl -MTest::More -le 'plan tests => 1; ok (1,1)' > 1..1 > # You named your test '1'. You shouldn't use numbers for your test >names. > # Very confusing. ok() is not a comparison. is() is a comparison. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: changes to T::H to enable continuous testing
On Sun, Feb 08, 2004 at 08:41:59AM -0600, Scott Bolte ([EMAIL PROTECTED]) wrote: > I agree, but I still believe it would be good if Test::Harness > laid out syntax rules for extensions. There are no extensions. They're up to whoever wants to. I'm certainly not going to define arbitrary rules based on a sample size of one. I DO want to document the format, however, so that other languages can write to the T::H format reliably, and let T::H become the uber-tester. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: changes to T::H to enable continuous testing
> Please let me know when you do document the format and make > sure to allow for extensions. I urge you do to so before > the sample size, and divergent extensions, gets too large. Patches are always welcome. Also, I don't see any sample size greater than one on this, unless I'm missing something. -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Smoking CPAN
> I've had more time recently, so I smoke tested the Phalanx 100. So what did you discover? xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Send me kwalitee news, please.
I'd like to put some kind of reasonably fresh content up on qa.perl.org. If anyone's got, say, module announcements, that would make sense to appear on qa.perl.org, please send 'em to me. I'd just like qa.p.o to be more than a pile of links. thanks, xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Aborting testsuits
> Because it is, in Test::More. I've yet to need it. Nobody's given me a > patch to implement it. And T::H doesn't recognize anything like that either? -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Hoplites, report!
It's been a while since I've heard from any hoplites. Where are you on your individual Phalanx modules? I know Hoplite Gessner is pretty close to done on his, but I haven't heard back on whether his changes were accepted. xoxo, Commander Andy -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: [ANNOUNCE] Devel::Cover 0.35
> Probably the most important change is that Devel::Cover will now work > with programs that turn on tainting. I gather this is important for > Phalanx. Hi Andy! Never mind Phalanx, I'd just like to run Test::Harness under it! I'll let you know what I find! -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: [ANNOUNCE] Devel::Cover 0.35
> Probably the most important change is that Devel::Cover will now work > with programs that turn on tainting. I gather this is important for > Phalanx. Hi Andy! Test::Harness is now more happy, but not entirely so, at running under Devel::Cover. I'll investigate more tonight. Thanks for the updates! xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Devel::Cover - require 5.8?
> I am considering dropping support for Perl 5.6 in Devel::Cover. Whilst > Devel::Cover basically works with Perl 5.6.1 and Perl 5.6.2, there are > many parts which are difficult or impossible to implement, leading to > certain constructs which cannot be covered. I think something like D::C is pretty bleeding edge, and it's OK to require 5.8. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: rfc: prove -p passthrutag=passthruval -p tag2=val2 @testfiles
> Id like to propose that I (or someone like me) add a passthru option > which lets someone pass thru options and arguments to the test scripts > being run. Is this better than some kind of environment variable that you set, and that your test programs detect and use? xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: rfc: prove -p passthrutag=passthruval -p tag2=val2 @testfiles
> thats precisely what -v does currently, same convenience argument applies. I see a difference in that prove -v is shorthand for TEST_VERBOSE=1 make test I'm not against the idea. Just not sure about the implementation. Whyncha write the manpage docs for how it'll work? That'll give us something more definite to base it on. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: reporting bugs to RT
I wonder if rt.cpan.org is broken. I'm trying to close ticket #2658 for Log::Procmail, but I can't tell rt when it's been fixed, since it show only version 0.01 to 0.05, when CPAN already holds 0.08 (0.06 and 0.07 have come and gone, since I try to tidy up behind me). I believe that at one point, Jesse Vincent was having problems with RT, and was moving, and got hacked, all within about a week of each other or so, so syncing with CPAN didn't happen. Something like that. xoa -- Andy Lester [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
Re: hoplite report for DBI : Part 2
Why should you guys have all the fun? Here's my patch.
* Adds a -T flag ('cause really, shouldn't all of DBI be able to run
under taint mode?)
* Uses Test::More instead of Test.
* Escapes out properly with skip_all.
* Adds an isa_ok() for all object creation statements.
* Added some comments here and there.
xoxo,
Andy
Index: t/42prof_data.t
===
--- t/42prof_data.t (revision 335)
+++ t/42prof_data.t (working copy)
@@ -1,24 +1,17 @@
-#!perl -w
+#!perl -wT
use strict;
-#
-# test script for DBI::ProfileData
-#
+use Test::More;
-use DBI;
-use DBI::ProfileDumper;
-use DBI::ProfileData;
+plan skip_all => "profiling not supported for DBI::PurePerl" if $DBI::PurePerl;
BEGIN {
-if ($DBI::PurePerl) {
- print "1..0 # Skipped: profiling not supported for DBI::PurePerl\n";
- exit 0;
-}
+plan tests=>33;
+use_ok( 'DBI' );
+use_ok( 'DBI::ProfileDumper' );
+use_ok( 'DBI::ProfileData' );
}
-use Test;
-BEGIN { plan tests => 18; }
-
use Data::Dumper;
$Data::Dumper::Indent = 1;
$Data::Dumper::Terse = 1;
@@ -27,10 +20,12 @@
my $dbh = DBI->connect("dbi:ExampleP:", '', '',
{ RaiseError=>1, Profile=>"6/DBI::ProfileDumper" });
+isa_ok( $dbh, 'DBI::db', 'Created connection' );
# do a little work
foreach (1,2,3) {
my $sth = $dbh->prepare($sql);
+ isa_ok( $sth, 'DBI::st', 'Created handle' );
for my $loop (1..20) {
$sth->execute(".");
$sth->fetchrow_hashref;
@@ -43,31 +38,30 @@
# wrote the profile to disk?
-ok(-s "dbi.prof");
+ok(-s "dbi.prof", "Profile written to disk, non-zero size" );
# load up
my $prof = DBI::ProfileData->new();
-ok($prof);
-ok(ref $prof eq 'DBI::ProfileData');
+isa_ok( $prof, 'DBI::ProfileData' );
+cmp_ok( $prof->count, '>=', 3, 'At least 3 profile data items' );
-ok($prof->count() >= 3);
-
# try a few sorts
my $nodes = $prof->nodes;
$prof->sort(field => "longest");
my $longest = $nodes->[0][4];
-ok($longest);
+ok( $longest, 'Longest is non-zero' );
$prof->sort(field => "longest", reverse => 1);
-ok($nodes->[0][4] < $longest);
+cmp_ok( $nodes->[0][4], '<', $longest );
$prof->sort(field => "count");
my $most = $nodes->[0];
ok($most);
$prof->sort(field => "count", reverse => 1);
-ok($nodes->[0][0] < $most->[0]);
+cmp_ok( $nodes->[0][0], '<', $most->[0] );
# remove the top count and make sure it's gone
my $clone = $prof->clone();
+isa_ok( $clone, 'DBI::ProfileData' );
$clone->sort(field => "count");
ok($clone->exclude(key1 => $most->[7]));
@@ -78,6 +72,7 @@
# there can only be one
$clone = $prof->clone();
+isa_ok( $clone, 'DBI::ProfileData' );
ok($clone->match(key1 => $clone->nodes->[0][7]));
ok($clone->match(key2 => $clone->nodes->[0][8]));
ok($clone->count == 1);
@@ -90,6 +85,7 @@
# test escaping of \n and \r in keys
$dbh = DBI->connect("dbi:ExampleP:", '', '',
{ RaiseError=>1, Profile=>"6/DBI::ProfileDumper" });
+isa_ok( $dbh, 'DBI::db', 'Created connection' );
my $sql2 = 'select size from . where name = "LITERAL: \r\n"';
my $sql3 = "select size from . where name = \"EXPANDED: \r\n\"";
@@ -97,10 +93,12 @@
# do a little work
foreach (1,2,3) {
my $sth2 = $dbh->prepare($sql2);
+ isa_ok( $sth2, 'DBI::st' );
$sth2->execute();
$sth2->fetchrow_hashref;
$sth2->finish;
my $sth3 = $dbh->prepare($sql3);
+ isa_ok( $sth3, 'DBI::st' );
$sth3->execute();
$sth3->fetchrow_hashref;
$sth3->finish;
@@ -109,7 +107,7 @@
# load dbi.prof
$prof = DBI::ProfileData->new();
-ok($prof and ref $prof eq 'DBI::ProfileData');
+isa_ok( $prof, 'DBI::ProfileData' );
# make sure the keys didn't get garbled
$Data = $prof->Data;
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: hoplite report for DBI : Part 2
OK, one more for tonight. It's the last of the Test.pm-using .t files.
Index: t/41prof_dump.t
===
--- t/41prof_dump.t (revision 335)
+++ t/41prof_dump.t (working copy)
@@ -1,36 +1,27 @@
-#!perl -w
+#!perl -Tw
use strict;
-#
-# test script for DBI::ProfileDumper
-#
+use Test::More;
-use DBI;
-use DBI::ProfileDumper;
+plan skip_all => "profiling not supported for DBI::PurePerl" if $DBI::PurePerl;
BEGIN {
-if ($DBI::PurePerl) {
- print "1..0 # Skipped: profiling not supported for DBI::PurePerl\n";
- exit 0;
-}
+plan tests => 11;
+use_ok( 'DBI' );
+use_ok( 'DBI::ProfileDumper' );
}
-use Test;
-BEGIN { plan tests => 7; }
-
-use Data::Dumper;
-$Data::Dumper::Indent = 1;
-$Data::Dumper::Terse = 1;
-
my $dbh = DBI->connect("dbi:ExampleP:", '', '',
{ RaiseError=>1, Profile=>"DBI::ProfileDumper" });
-ok(ref $dbh->{Profile}, "DBI::ProfileDumper");
-ok(ref $dbh->{Profile}{Data}, 'HASH');
-ok(ref $dbh->{Profile}{Path}, 'ARRAY');
+isa_ok( $dbh, 'DBI::db' );
+isa_ok( $dbh->{Profile}, "DBI::ProfileDumper" );
+isa_ok( $dbh->{Profile}{Data}, 'HASH' );
+isa_ok( $dbh->{Profile}{Path}, 'ARRAY' );
# do a little work
my $sql = "select mode,size,name from ?";
my $sth = $dbh->prepare($sql);
+isa_ok( $sth, 'DBI::st' );
$sth->execute(".");
$sth->{Profile}->flush_to_disk();
@@ -42,22 +33,21 @@
undef $dbh;
# wrote the profile to disk?
-ok(-s "dbi.prof");
+ok( -s "dbi.prof", 'Profile is on disk and nonzero size' );
open(PROF, "dbi.prof") or die $!;
my $prof = join('', );
close PROF;
# has a header?
-ok($prof =~ /^DBI::ProfileDumper\s+([\d.]+)/);
+ok( $prof =~ /^DBI::ProfileDumper\s+([\d.]+)/, 'Found a version number' );
+# Can't use like() because we need $1
# version matches VERSION? (DBI::ProfileDumper uses $self->VERSION so
# it's a stringified version object that looks like N.N.N)
-ok($1, DBI::ProfileDumper->VERSION);
+is( $1, DBI::ProfileDumper->VERSION, 'Version numbers match' );
# check that expected key is there
-ok($prof =~ /\+\s+1\s+\Q$sql\E/m);
+like( $prof, qr/\+\s+1\s+\Q$sql\E/m );
# unlink("dbi.prof"); # now done by 'make clean'
-
-1;
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
DBI tests
I've committed my t/41 and t/42 changes to subversion. They are not the same as what I submitted to the list. > Is there any reason to now use skip_all? (Remember, you're wearing > the official "Test Expert" hat now so you need to weigh up the > issues and make recommendations :) We can't use skip_all, because the t/zv_pp* files have to run their non-zv_pp counterparts as well. I put it back the way it was. I wanted to use skip_all so that we aren't doing roll-your-own on things that already are well-defined. > One concern just popped into my head... I'd like to not have to > depend on very recent versions of Test::More. Can you look into > that and make recommendations about what version of Test::More > we should use as a minimum? Earliest on CPAN is 0.45, and that should be just fine. I don't see anything in the Changes file that tells me otherwise. The most "very recent" version of Test::More is from August 2002. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: hoplite report for DBI : Part 2
On Tue, May 11, 2004 at 01:58:51PM -0400, stevan little ([EMAIL PROTECTED]) wrote: > Should we put the -T flag in all the test files? I can do that if so. I'd like to. I'd like every module to think about taint-safety. DBI especially, since we're dealing with tainted data if it comes from a DB, should be taint-aware, I think. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: How can I get involved in the Phalanx Project
On Fri, May 07, 2004 at 08:12:32AM -0500, James.FitzGibbon ([EMAIL PROTECTED]) wrote: > > Or...we could set some deadlines...like have 50% of your module tested > by YAPC, and/or possibly have some incentives. > > How about asking YAS if they would offer reduced price admission if you > flesh out the test suite for x modules? Well, let me ask the hoplites who haven't even responded to my last email asking for a status report: Why have your modules stagnated? In my case, Test::Reporter was sort of a pain to get my head around, and then other, sexier (and sometimes paying) projects came to the fore. Let's understand the problem before proposing solutions. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: How can I get involved in the Phalanx Project
On Fri, May 07, 2004 at 10:31:49PM +0100, Tim Bunce ([EMAIL PROTECTED]) wrote: > Here's what I'd like to see done soonish: > > 1. Convert all exisiting test files to Test::More > 2. Parts of t/10examp.t should be broken out to separate test scripts > 3. Start increasing coverage, especially prior to DBI v2. Did I not hit all the existing test files? Or just some of 'em? Also, look into using Devel::Cover to see which parts of DBI are getting exercised and which aren't. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Testing quickref
Ian Langworth has created a great quickref for Test::* modules at http://langworth.com/downloads/perl_test_refcard.pdf. I put a link to it up on qa.perl.org. xoxo, Andy -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: reporting bugs to RT
On Wed, May 05, 2004 at 11:40:32PM -0200, Gabor Szabo ([EMAIL PROTECTED]) wrote: > Is there some command line tool that can be used to report bugs to RT ? Sure, it's called "sendmail". If you want to send a bug on Test::Harness, send an email to [EMAIL PROTECTED] xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: reporting bugs to RT
On Thu, May 06, 2004 at 12:44:58AM -0200, Gabor Szabo ([EMAIL PROTECTED]) wrote: > I guess this answer also means that there is no script similar to > perlbug that would report bugs about CPAN modules ? > Wouldn't this help increasing the use or RT ? Not everyone uses RT. Many authors ignore it, I'm sure. I have a note in my modules saying "Please send all requests to". xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: hoplite report for Parse::RecDescent
On Fri, May 07, 2004 at 08:28:36AM +0200, Dominic Letarte ([EMAIL PROTECTED]) wrote: > ok, I have written 8 tests scripts for a total of 227 tests cases (11 > tests cases are presents in the current distribution of PRD). My test > code is covering all the things said in the first half of the pod file. > I put some bugs in rt. I have abandonned the idea of writing tests for > the tings in the demo directory for the moment. That's great! That's better than there was before. Can you send your diffs back to Damian to incorporate? No rules that say "We can only incorporate tests when everything is covered." ANY amount of test improvement is still an improvement. I sent some DBI test patches a month ago, and I thought Tim Bunce was going to reach through the monitor and give me a big wet kiss. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: DBI tests update
Not having a threaded version of perl handy right now (I am home, it is at work), I cannot test this right now. The changes I had made were only to change a few tests to 'cmp_ok' and add test names, which should not affect things. However in the last update (prior to this one), I did change the order in which things were loaded when I converted this to use 'skip_all'. I did not think this would affect things, but without a threaded perl handy and limited knowledge of the details of threaded perl I suppose I should not have assumed. It is a problem with Test::Builder and threading, and it relates to, I believe, overloaded stringification of objects. At least, that's what it was when I was having a similar problem in WWW::Mechanize's tests and it was using an automagically stringified URI::URL object. I had to explicitly call $obj->as_string and then it was happy. YMMV. xoxo, Andy -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: DBI tests update
On Sat, May 15, 2004 at 04:22:05PM -0400, stevan little ([EMAIL PROTECTED]) wrote: > This stringification problem may be a culprit, as we stringify 2 > objects to test against in the subroutine which is run in each thread. > But that stringification was there before in the old test (1.42), so I > think maybe this is a different problem. One easy, empirical way to find out! xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Test functions return values.
On Tue, May 25, 2004 at 09:16:51AM -0700, chromatic ([EMAIL PROTECTED]) wrote:
> On Tue, 2004-05-25 at 06:58, Francisco Olarte Sanz wrote:
> It's a reliable feature. If it's not documented, it should be.
It should also be stated so that folks who use Test::Builder know to
make their functions return T/F as a convention.
I've seen functions before that look like this:
sub foo_ok {
my $value = shift;
my $msg = shift;
my $ok = wango_dango_whatever( $value );
$Test->ok( $ok, $msg );
diag( "Blah blah" ) unless $ok;
}
Of coruse, the final line there should be a simple "return $ok".
xoa
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Adding analysis to Devel::Cover reports
When you hover the mouse over one of the percentages, you get a little
pop-up
that gives the numbers used to calculate the percentage. ("Tooltip"
probably
isn't the right name for this situation, but that's what I'm used to
calling them.)
The "ALT attribute as tooltip" thing isn't portable, though.
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
My Phalanx lightning talk
So I'm giving an LT on Phalanx next week in Buffalo. Anything in particular y'all think I should mention? xoxo, Andy To: Andy Lester <[EMAIL PROTECTED]> Subject: Your Lightning Talk Your proposal for a Lightning Talk at the 2004 YAPC::America::North has been accepted. topic: Join the Phalanx project description: A brief discussion of Phalanx, a project devoted to increasing the testing coverage of Perl and the key modules on the CPAN. I'll discuss where we're at, and call for participation from interested parties. -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: My Phalanx lightning talk
On Thu, Jun 10, 2004 at 03:35:23PM +0100, Nicholas Clark ([EMAIL PROTECTED]) wrote: > Well, how people acn help, particularly how they can help even if they don't > think they have time to be *the* one true hoplite for a project. I'm thinking that maybe instead of people picking a module to do, and then working on it, which has so far not worked at all, that we should hold up a module (or a handful of them) and say "OK, this is what we're working on". It certainly seemed to work with the DBI stuff last month. Thoughts? xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: empty tests, Test::Harness, and Test::Inline
On Fri, Jun 11, 2004 at 02:16:36PM -0400, Andrew Pimlott ([EMAIL PROTECTED]) wrote: > 2. Test::Harness::runtests complains "FAILED before any test output > arrived" on empty test files. It would be convenient if it simply > skipped them. As it is, I "grep -s" them out in my build script. Seems to me that if T:H is passed a test file, it's not unreasonable for it to expect at least one test. How about if T:I created a dummy test in the absence of any others? xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: empty tests, Test::Harness, and Test::Inline
On Fri, Jun 11, 2004 at 03:33:44PM -0400, Andrew Pimlott ([EMAIL PROTECTED]) wrote: > I prefer to eliminate extra noise. The situation I'm in is, I just > started using T::I, so only a few modules have any tests, and I would > see dozens of spurious "ok" lines for untested modules. I agree about skipping noise, but then you'd have T::H ignoring empty files, which might, in another case, indicate something gravely wrong. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Perl Test-First Kata
On Fri, Jun 18, 2004 at 12:03:51PM -0700, chromatic ([EMAIL PROTECTED]) wrote: > Is anyone else interested in writing some small excercises for people to > practice their Perl test-fu? Yes. A lot. I think it'll bring many to the light. xox, Andy -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: C/C++ White-Box Unit Testing and Test::More
On Fri, Jun 25, 2004 at 04:51:29PM +0100, Fergal Daly ([EMAIL PROTECTED]) wrote: > > * I never have to type repetitive tests like > > > > isa_ok Foo->new(), 'Foo' > > > > again because it's handled by a base class that all my test classes > > inherit from. Repetition is good. I feel very strongly that you should be checking your constructor results in every single test, and checked against literals, not variables. my $foo = My::Foo->new(); isa_ok( $foo, 'My::Foo' ); # and then use it. # # Later on... my $foo = My::Foo->new( bar => 14, bat => \$wango ); isa_ok( $foo, 'My::Foo' ); The more checks you have, the better. Sure, the first isa_ok technically "covers" the constructor, but why not check after EVERY constructor? The 2nd example is really an entirely different test. Tests are all about quantity. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: WWW::Mechanize and ASP.NET
On Fri, Jun 25, 2004 at 03:35:38PM -0400, Potozniak, Andrew ([EMAIL PROTECTED]) wrote: > Has anyone encountered some really odd errors, namely status 500 errors when > surfing to ASP.Net files only through means of WWW::Mechanize? What is the error that is showing up in the log file on your ASP.Net side? A 500 error is a problem on the server. That error is logged somewhere on the server. This isn't a Mech problem. xoxo, Andy -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: how to run test.pl before the t/*.t tests ?
On Thu, Jul 08, 2004 at 04:20:38PM -0400, Michael G Schwern ([EMAIL PROTECTED]) wrote: > > > [2] Want some fun? http://search.cpan.org/~dconway > > > > You have a sick sense of humour young man ;) > > He uses test.pl. Sic 'em. That sort of cleanup is exactly what Phalanx is about. I think Parse::RecDescent is on the Phalanx 100. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Phalanx: What if full coverage isn't possible? (fwd)
> There's a whole set of these sort of problems.
>
> sub new {
> my $proto = shift;
> my $class = ref $proto || $proto;
In this case, we probably don't want that ANYWAY. That's what I did
when I was through Data::Page for Leon Brocard, and it's now at 100%
coverage, across the board (at least the patches I sent).
> Don't be mesmerized by 100% coverage.
Agreed 100% here. However, I stand by my original statement that you
CAN have 100% coverage on subroutines and pod. Any disagreement on that
one?
> Test coverage is a useful *heuristic* for test effectiveness. Like all
> heuristics if you push it too far it falls apart. Get as close to 100% as
> is useful and don't worry about the rest.
Words to live by.
xoa
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Phalanx: What if full coverage isn't possible? (fwd)
On Sun, Jul 11, 2004 at 12:26:44PM -0400, stevan little ([EMAIL PROTECTED]) wrote: > As for POD, in most cases, I agree with you, but to say you should have > 100% POD coverage brings up several other questions, such as; Should I > document private methods? What about modules which are meant to be > configured in the "use" statement, and have little or no subroutines Devel::Cov er handles this for you. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Phalanx: What if full coverage isn't possible? (fwd)
On Sun, Jul 11, 2004 at 03:07:22PM -0400, stevan little ([EMAIL PROTECTED]) wrote:
> I think that reg-ex is too loose (and incorrect, but I know you really
> meant /^[A-Z]+$/). I would rather see it check for all the documented
> magic methods rather than a catch all for UPPERCASE names. Even though
This also ignores the constants that we usually make all-caps.
use constant PANTS => 42; # is actually sub PANTS() {42}
I'm not sure if that's a feature or a problem.
xoa
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Data::Page is at 100%
Last week, I retroed some tests on Data::Page and it now covers at 100%. Had to add a couple of constructor tests. Note also that all its tests are running under -T. http://search.cpan.org/dist/Data-Page/ It's a small module, but it worked very nicely. "Hey, Leon, you want updates to tests?" "Yeah!" "OK, here you go" "Thanks, released!" xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: [ANNOUNCE] Test::Simple 0.48_02
On Mon, Jul 19, 2004 at 04:25:35PM +0100, Adrian Howard ([EMAIL PROTECTED]) wrote: > Which causes anything testing test diagnostic output with > Test::Builder::Tester to fall over. Test::Class, Test::Exception & > Test::Block's test suites now all fail. Ooof, good catch. I'd really hate to have my Test::* stuff rely on a given instance of Test::More. > My temptation is to say the new behaviour is the right one and patch > T::B::T and friends? I'd agree. I like the new behavior that's described. And if TBT could handle either form of diag, that would be the most swell. xoxo, Andy -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Little lost wiki...
The Perl QA Wiki linked to from <http://qa.perl.org/> as <http://www.pobox.com/~schwern/cgi-bin/perl-qa-wiki.cgi> eventually ends up as a 403 at <http://mungus.schwern.org/~schwern/cgi-bin/perl-qa-wiki.cgi>. Probably dead, because Ingy was to set up qa.kwiki.org and phalanx.kwiki.org, too, when we were together at OSCON. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Test-Regex-0.01.tar.gz
Started a new module, Test::Regex, as a proof of concept. Not sure it's something that's useful (although to at least one person it is), or if it should be rolled into Test::More to avoid code duplication, or what. Lets you check the dollar vars of your results matches_are( "dog food", qr/dog(.+)/, 1=>"food", "Matched OK" ); or matches_are( "first middle end", qr/middle|center/, "&" => "middle", "`" => "first " ); Eventually we'll handle the punc vars, but for now this will do. Thoughts? xoa - Forwarded message from PAUSE <[EMAIL PROTECTED]> - The uploaded file Test-Regex-0.01.tar.gz has entered CPAN as file: $CPAN/authors/id/P/PE/PETDANCE/Test-Regex-0.01.tar.gz size: 2890 bytes md5: 565b7e75907b621dfc411bb967b38fe7 No action is required on your part Request entered by: PETDANCE (Andy Lester) Request entered on: Mon, 02 Aug 2004 03:14:00 GMT Request completed: Mon, 02 Aug 2004 03:15:14 GMT Thanks, -- paused, v460 - End forwarded message - -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Phalanx coverage dumping
I'm going to try something crazy. Crazy for me. I'm going to delegate things I'd like done. Or at least throw them out there for someone to grab on to and do themselves. Rather than keep the idea in my head until I get time to do it, which will not be soon. It'd be swell if someone generated Devel::Cover dumps for the Phalanx 100. Like http://pjcj.sytes.net/cpancover/ but for http://qa.perl.org/phalanx/distros.html. I also wonder if the 100 would be different now than when I created it a year ago. xoxo, Andy -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Redoing the Phalanx 100
I'll be redoing the Phalanx 100 this week. I'm hoping to get FTP logs from pair.com and from cpan.org. If anyone else has FTP logs they can submit to me, I'd love to have 'em. xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Redoing the Phalanx 100
$ host cpan.org cpan.org has address 66.39.76.93 $ host cpan.pair.com cpan.pair.com has address 66.39.76.93 Last year, I got different logs from Graham and Pair. Any other suggestions since they're apparently the same now? Mirror-owners I should talk to? xoa -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Patch for t/op/sleep.t
t/op/sleep.t doesn't actually check to see how long it's slept for. The
test takes sleep()'s word for it.
I also modernized it to use Test::More and its convenience functions.
xoxo,
Andy
--- t/op/sleep.t.orig 2004-08-08 23:19:54.0 -0500
+++ t/op/sleep.t2004-08-08 23:52:11.0 -0500
@@ -1,8 +1,15 @@
#!./perl
-# $RCSfile: sleep.t,v $$Revision: 4.1 $$Date: 92/08/07 18:28:23 $
+use strict;
+use warnings;
+use Test::More tests=>4;
-print "1..1\n";
+my $start = time;
+my $sleep_says = sleep 3;
+my $diff = time - $start;
-$x = sleep 3;
-if ($x >= 2 && $x <= 10) {print "ok 1\n";} else {print "not ok 1 $x\n";}
+cmp_ok( $sleep_says, '>=', 2, 'Sleep says it slept at least 2 seconds' );
+cmp_ok( $sleep_says, '<=', 10, '... and no more than 10' );
+
+cmp_ok( $diff, '>=', 2, 'Actual time diff is at least 2 seconds' );
+cmp_ok( $diff, '<=', 10, '... and no more than 10' );
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Test for functions with operator names
Here's a test file that makes sure that even with sub q{}, that q() is
an operator, but &q() and main::q() are function calls. I suggest that
it be called t/comp/operator-subs.t.
A transcription of the IRC conversation that started this discussion is
at the bottom of this file. So often we have these discussions where a
topic is discussed and decided, it would be nice if they turned into
tests that define the behavior. I've spent only about 90 mins working
on this test file, so it's not like writing these tests is a big time
suck. Next time we get into behavior discussions, let's get a
deliverable of a .t file out of them.
Thanks,
xoxo,
Andy
#./perl -T
use warnings;
use strict;
$|++;
=pod
Even if you have a C, calling C will be parsed as the
C operator. Calling C<&q()> or C gets you the function.
This test verifies this behavior for nine different operators.
=cut
use Test::More tests => 36;
sub m { return "m-".shift }
sub q { return "q-".shift }
sub qq { return "qq-".shift }
sub qr { return "qr-".shift }
sub qw { return "qw-".shift }
sub qx { return "qx-".shift }
sub s { return "s-".shift }
sub tr { return "tr-".shift }
sub y { return "y-".shift }
# m operator
can_ok( 'main', "m" );
SILENCE_WARNING: { # Complains because $_ is undef
no warnings;
isnt( m('unqualified'), "m-unqualified", "m('unqualified') is oper" );
}
is( main::m('main'), "m-main", "main::m() is func" );
is( &m('amper'), "m-amper", "&m() is func" );
# q operator
can_ok( 'main', "q" );
isnt( q('unqualified'), "q-unqualified", "q('unqualified') is oper" );
is( main::q('main'), "q-main", "main::q() is func" );
is( &q('amper'), "q-amper", "&q() is func" );
# qq operator
can_ok( 'main', "qq" );
isnt( qq('unqualified'), "qq-unqualified", "qq('unqualified') is oper" );
is( main::qq('main'), "qq-main", "main::qq() is func" );
is( &qq('amper'), "qq-amper", "&qq() is func" );
# qr operator
can_ok( 'main', "qr" );
isnt( qr('unqualified'), "qr-unqualified", "qr('unqualified') is oper" );
is( main::qr('main'), "qr-main", "main::qr() is func" );
is( &qr('amper'), "qr-amper", "&qr() is func" );
# qw operator
can_ok( 'main', "qw" );
isnt( qw('unqualified'), "qw-unqualified", "qw('unqualified') is oper" );
is( main::qw('main'), "qw-main", "main::qw() is func" );
is( &qw('amper'), "qw-amper", "&qw() is func" );
# qx operator
can_ok( 'main', "qx" );
eval "qx('unqualified')";
like( $@, qr/^Insecure/, "qx('unqualified') doesn't work" );
is( main::qx('main'), "qx-main", "main::qx() is func" );
is( &qx('amper'), "qx-amper", "&qx() is func" );
# s operator
can_ok( 'main', "s" );
eval "s('unqualified')";
like( $@, qr/^Substitution replacement not terminated/, "s('unqualified') doesn't
work" );
is( main::s('main'), "s-main", "main::s() is func" );
is( &s('amper'), "s-amper", "&s() is func" );
# tr operator
can_ok( 'main', "tr" );
eval "tr('unqualified')";
like( $@, qr/^Transliteration replacement not terminated/, "tr('unqualified') doesn't
work" );
is( main::tr('main'), "tr-main", "main::tr() is func" );
is( &tr('amper'), "tr-amper", "&tr() is func" );
# y operator
can_ok( 'main', "y" );
eval "y('unqualified')";
like( $@, qr/^Transliteration replacement not terminated/, "y('unqualified') doesn't
work" );
is( main::y('main'), "y-main", "main::y() is func" );
is( &y('amper'), "y-amper", "&y() is func" );
=pod
from irc://irc.perl.org/p5p 8/12/2004
kane-xs bug or feature?
purlYou decide
kane-xs [EMAIL PROTECTED] ~]$ perlc -le'sub y{1};y(1)'
kane-xs Transliteration replacement not terminated at -e line 1.
Nicholasbug I think
kane-xs i'll perlbug
rgs feature
kane-xs smiles at rgs
kane-xs done
rgs will be closed at not a bug,
rgs like the previous reports of this one
Nicholasfeature being first class and second class keywords?
rgs you have similar ones with q, qq, qr, qx, tr, s and m
rgs one could say 1st class keywords, yes
rgs and I forgot qw
kane-xs hmm silly...
Nicholasit's acutally operators, isn't it?
Nicholasas in you can't call a subroutine with the same name as an
operator unless you have the & ?
kane-xs or fqpn (fully qualified package name)
kane-xs main::y() works just fine
kane-xs as does &y; but not y()
AndyIf that's a feature, then let's write a test that it continues
to work like that.
=cut
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
