Re: building a watchdog
My initial thought would be simply to have a series of test programs to verify everything that you need. Then set up a cron job and just run 'em through Test::Harness and pipe the output to your favorite mail program. perl -MTest::Harness -e 'runtests(glob "/path/to/tests/*.t")' 2>&1 | mail [EMAIL PROTECTED] I don't think much special work would need to be done. I've heard that Test::Cmd works pretty well. I was reading that just a few days ago, but I can't remember where I read that (grr ...) Cheers, Ovid --- "Randal L. Schwartz" <[EMAIL PROTECTED]> wrote: > > It occurs to me that that if I wanted to build a health check > watchdog for my system (a script that executes at regular intervals > to ensure proper operation), that the Test::* mechanisms would > be pretty ideal for checking the results and reporting the proper > errors. > > I can't be treading new ground here. Has anyone done this already > and could pass along pointers, or better yet, working code? > > [Aside - is Test::Cmd considered current tech? It hasn't been updated > in two years... is there a better way?] > > Thanks. > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> > Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. > See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! = Hire me! http://users.easystreet.com/ovid/personal/resume.html Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
RE: passing arguments to tests
I'm afraid your code won't work.
> package TestHarnessSubClass;
[snip]
> #This creates TestHarnessSubClass into a sub class of Test::Harness
> use base "Test::Harness";
[snip]
> sub runtests{
> my $self = shift;
[snip]
> $self->SUPER::runtests(@_);
> }
Okay, you've subclassed a functional module. But this means that you'll be passing
the package
name as the first argument, not a test name. This will generate a "this test does not
exist"
warning with the package name as the name of the first test that it's trying to run.
On a minor side note, $self in Perl typically refers to an instance. If this were a
proper class
method, $class would be a better name for that argument.
> use TestHarnessSubClass;
> TestHarnessSubClass::runtests('c:\perl\sample.t')
You subclassed Test::Harness, but here you are still calling this in a functional
manner (instead
of TestHarnessSubClass->runtests), which means that C:\perl\sample.t will be passed as
the first
argument. The "subclassed" runtests() method will assign that value to $self and you
will have
very disappointing results.
In short, don't try to subclass modules unless they're OO.
Cheers,
Ovid
=
Hire me! http://users.easystreet.com/ovid/personal/resume.html
Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: Blurring the line between assertions and tests
--- chromatic <[EMAIL PROTECTED]> wrote:
> On Friday, August 1, 2003, at 05:03 PM, Michael G Schwern wrote:
>
> > Ooooh! I just had a great idea. Use "TEST { ... }" instead of "TEST:
> > { ... }"
> > in Test::AtRuntime.
>
> Could these instead be subroutine attributes? I can see a lot of
> advantages there.
That would be much nicer. I am so used to writing SKIP: {} and TODO: {} that I
scratch my head
and wonder why my cleanup doesn't work in END: {}. The presence or absence of that
little colon
causes me enough grief that I suspect having such a subtle difference as TEST {}
versus TEST: {}
is begging for trouble.
This does mean, though, that it won't play nicely with versions of Perl < 5.6.0. Is
that trade
off acceptable?
Cheers,
Ovid
=
Silence is Evil http://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: Testers & PASS
--- Tels <[EMAIL PROTECTED]> wrote: > Hm, it generates fast, but wrong results :-) > > Math::BigInt: [snip] I have to concur. From HTML::TokeParser::Simple results I conclude two things: 2.1 (3 PASSes) 92430 PASS sun4-solaris 92784 PASS MSWin32-x86-multi-thread 93059 PASS i586-linux 2.0 (6 PASSes) 91811 PASS sun4-solaris 91840 PASS i586-linux 92801 PASS MSWin32-x86-multi-thread 1: Older versions are getting cumulative results from newer versions. 2: Everyone rushed out to check their own modules :) Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Testing strategies
Hi all,
The company I now work for uses testing modules developed here several years ago. One
of my
coworkers is curious to know how Perl's standard testing modules compare to the ones
they use.
He'll happily consider going with Perl's testing modules if there is a compelling
reason to do so.
I'm not particularly advocating one way or another, but I promised him I would shoot
an email to
the Perl QA list and ask for feedback. Frankly, I'm happy just to have testing here.
This is rather long and contains a fair number of samples, so I beg your patience.
Thanks!
Here's some sample code (stripped down for clarity):
package RTK::Retail::Product::TEST::Supplier;
use base qw/RTK::Retail::Meta::TestCase/;
use RTK::Meta::Test::Asserts;
use RTK::Retail::Product::TEST::Supplier::TestUtil;
use Aliased 'RTK::Retail::Product::Supplier';
sub TEST_FIND_ALL
{
assert_lists_eq([Supplier->find_all], []);
my $supplier1 = create_test_supplier(
-supplier_no => 1,
-name => 'Foo, Inc.'
);
my $supplier2 = create_test_supplier(
-supplier_no => 2,
-name => 'Bar, Inc.'
);
my @suppliers = sort map { $_->name } Supplier->find_all;
my @actual_suppliers = ('Bar, Inc.', 'Foo, Inc.');
assert_lists_eq([EMAIL PROTECTED],[EMAIL PROTECTED]);
my $supplier3 = create_test_supplier(
-supplier_no => 3,
-name => 'Baz, Inc.'
);
@suppliers = sort map { $_->name } Supplier->find_all;
@actual_suppliers = sort ('Baz, Inc.', 'Bar, Inc.', 'Foo, Inc.');
assert_lists_eq([EMAIL PROTECTED],[EMAIL PROTECTED]);
}
sub TEST_FIND_ALL_SORTED_BY_NAME
{
[snip]
Each /^TEST__\w+/ subroutine is run and has a number of asserts in it. Each test
subroutine is
considered to be a test of a single type of functionality and if all asserts pass, the
test is
considered successful. Here's a sample of the output, running one test.
TEST_FIND_ALL
TEST_FIND_ALL --> Passed! Life is Wonderful!
Running an entire test module (again, simplified for clarity):
TEST_FIND_ALL ..
Connecting to TEST database '[EMAIL PROTECTED]'
passed (0.12s - 0.07 CPU)
TEST_FIND_ALL_SORTED_BY_NAME ..passed (0.06s - 0.02 CPU)
The "Connecting to TEST database .." line is important. There are three test
databases are
completely empty. At the beginning of a test program, the user is assigned on of the
three
databases (test fails if all are in use) and they are responsible for populating it
with test
data. Those are the 'create_test_supplier' lines in the code. At the end of each
test function,
the data is automatically removed from the database. Each function has setup and
teardown
functions that are automatically run behind the scenes.
Running the entire test suite is simply a matter of using their rtk_test program which
spiders
through the entire directory structure and runs all tests that it finds in any module
(allowing
inline tests, if desired).
And a sample failure:
TEST_FIND_ALL ..
Connecting to TEST database '[EMAIL PROTECTED]'
FAILED!!
-- Test failed: Different values at index 1: 'Baz, Inc.' vs. 'Foo, Inc.': 'Baz,
Inc.' ne 'Foo,
Inc.' on /home/cxp/work/popup_sort/perl_lib/RTK/Retail/Product/TEST/Supplier.pm, line
34
Yikes!!. Errors in:
/home/cxp/work/popup_sort/perl_lib/RTK/Retail/Product/TEST/Supplier.pm
Let me know if anything is unclear. If you can think of any pros and cons of this
approach, I
would love to hear them.
Cheers,
Ovid
=
Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: passing arguments to tests
--- Andrew Savige <[EMAIL PROTECTED]> wrote:
> Fergal Daly wrote on 14 July 2003:
> > is it possible with Test::Harness and MakeMaker to pass arguments to
> > my test scripts? I think it's not but I just want to check for sure.
> > The module I'm working on is getting a new "optimised" mode so I'd like
> > to be able to run all the tests twice, once with and once without the
> > optimiser.
>
> Which module is this? What did you end up doing? I'm interested to study
> what you did, so as to learn new testing techniques.
I do something like the following to get this effect:
#!/usr/bin/perl -w
use strict;
use Test::Harness;
use Getopt::Long;
use Pod::Usage;
GetOptions(
'help|?'=> sub { pod2usage(-verbose => 2); exit },
'verbose!' => \$Test::Harness::verbose,
'quiet' => sub { $Test::Harness::verbose = 0 },
'include=s' => \my @include,
'exclude=s' => \my @exclude,
'shuffle' => \my $shuffle_tests,
'fast' => \$ENV{FAST_TESTS},
);
In this case, this is part of my driver script and I call it like:
grind --fast
That runs through all of my tests, but the "FAST_TESTS" environment variable is
available in the
test programs that I run.
Cheers,
Ovid
=
Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: Test::More and 'deep' tests
My opinion: those is_deeply() tests should probably not pass. While on the surface it may appear that they should, I would argue that this is a case where the programmer writing the tests needs to know enough about the system he or she is building to create tests that accurately reflect how the code will be used. This is fine: isa_ok($str2, ref $str1, '... and the object'); This is (almost) not fine: is($str2, $str1, '... and the strings are equal'); However, the latter (and is_deeply()) should work *If and Only If* that comparison is part of the documented interface. If it's not documented, I don't want an explicit test for behavior that might change from the standpoint of the person using the code. Of course, I don't mind testing internals that might change: people using the code won't be mucking with the internals. The problem, of course, is that this implies that the exact behavior of is_deeply() should change depending upon whether or not a particular use of code is documented. This is not what I mean. I suspect that we have a case where there is no clear cut answer, but the programmers writing tests need to know the pros and cons of different approaches. I hope that made sense. Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: passing arguments to tests
--- Andrew Savige <[EMAIL PROTECTED]> wrote:
> Oh, that 'grind' looks like a very handy command but I'm a bit
> confused about how you use it. Is it just a handy general-purpose
> command or do you use it specifically as part of "make test" in
> your CPAN distributions?
It's a utility that I wrote to allow me to better manage my tests.
> If you have used it in a CPAN module,
> please let me know which one, so I can take a look.
I've just made it available at
http://users.easystreet.com/ovid/cgi_course/downloads/grind.gz
It needs more work, including allowing descending into directories (via File::Find or
a similar
mechanism) and having pre and post actions. I haven't figured out the best way to do
the latter
(that would be things like setting up a test db, tearing it down afterwards, etc.)
> I assume grind calls Test::Harness:runtests() shortly after accepting
> these command-line options, running all "t/*.t" tests by default, and
> using @include and @exclude to include/exclude tests. Is that right?
Yes.
> What is --shuffle and --fast used for? Can you please give some
> examples of how you use it?
--shuffle will shuffle the order in which the tests are run to ensure that you have no
accidental
dependency on test order.
--fast sets and environment variable that can be checked in the test scripts. For
example, if you
have a couple of tests that double the time of your test run and you want a fast check
of
integrity, you can put this in your code:
SKIP: {
skip 'Fast Tests', 1 if $ENV{FAST_TESTS};
ok( really_long_running_function(), '... successfully kills time');
}
Fortunately, this is all documented in the POD :)
> BTW, is there a web site that allows you to search CPAN source code?
> For example, I might like to search all of CPAN for any distribution
> that contains Test::Harness in any file in the t/ directory.
Yes, it's called Google ;)
Actually, I don't think Google will be *that* specific, but use the following for your
search
terms:
site:search.cpan.org "use Test::Harness"
That will generate a lot of "probables".
Cheers,
Ovid
=
Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Devel::Cover can't find loaded modules
Hi all, I was running some test code with Devel::Cover and I've had no problem using it or generating pretty reports that make coworkers "ooh" and "ahh". Unfortunately, I started running my test suite on a different set of tests and started getting some strange errors (formatted for clarity): Devel::Cover: Can't find file "blib/lib/Text/CSV.pm": ignored. Can't locate object method "find_cv" via package "B::SPECIAL" (perhaps you forgot to load "B::SPECIAL"?) at /usr/local/stow/ASperl-5.6.1-629/lib/5.6.1/i686-linux/B.pm line 213. To narrow down the problem, I tried running this on a smaller set of tests, only to get the above output, but with the following line prepended: Devel::Cover: Can't find file "blib/lib/Storable.pm": ignored. I'm not sure how running fewer tests is generating more errors, but in digging through Devel::Cover, I can't even find a reference to Text::CSV, nor has digging through B.pm shed any light (though I may require therapy now). Googling has also been fruitless for me. Has anyone seen any errors like this before and can you give me some guidance on what I can do to alleviate them? I'm trying to create a small test case, but this has been pesky to narrow down. In the meantime, I'm going to try to add signal handlers to dump stack traces and maybe even symlink a 'blib/lib' to the appropriate libraries (what a nasty hack!). Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
Devel::Cover bug in ActiveState Perl for *Linux*
After much research, I've managed to reduce a Devel::Cover bug down to a one-liner
which only
fails on one box. This box is unique because it's ActiveState Perl for Linux (not my
choice!).
However, that might be a red herring. My 'perl -V' is below the test case. Does
anyone have a
similar setup which they can check this against?
--
$ perl -MDevel::Cover -e 'local *{"foo"} = sub {}'
Devel::Cover 0.26: Collecting coverage data for branch, condition, statement,
subroutine and time.
Pod coverage is unvailable. Please install Pod::Coverage from CPAN.
Selecting packages matching:
Ignoring packages matching:
Ignoring packages in:
.
/dp/usr/cxp/perl/lib
/usr/local/lib/perl5/site_perl
/usr/local/lib/perl5/site_perl/5.6.1
/usr/local/lib/perl5/site_perl/5.6.1/i686-linux-multi
/usr/local/stow/perl-5.6.1-a633/lib/perl5/5.6.1
/usr/local/stow/perl-5.6.1-a633/lib/perl5/5.6.1/i686-linux-multi
/usr/local/stow/perl-5.6.1-a633/lib/perl5/site_perl
/usr/local/stow/perl-5.6.1-a633/lib/perl5/site_perl/5.6.1
/usr/local/stow/perl-5.6.1-a633/lib/perl5/site_perl/5.6.1/i686-linux-multi
Can't locate object method "find_cv" via package "B::SPECIAL" (perhaps you forgot to
load
"B::SPECIAL"?) at
/usr/local/stow/perl-5.6.1-a633/lib/perl5/5.6.1/i686-linux-multi/B.pm line 213.
END failed--call queue aborted.
--
And the Perl -V
--
$ perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
Platform:
osname=linux, osvers=2.4.9-e.3, archname=i686-linux-multi
uname='linux bulkmailer 2.4.9-e.3 #1 fri may 3 17:02:43 edt 2002 i686 unknown '
config_args='-d -O -Dinstallstyle=lib/perl5
-Dprefix=/usr/local/stow/perl-5.6.1-a633
-Uinstallusrbinperl -Dd_dosuid=define -Dotherlibdirs=/usr/local/lib/perl5/site_perl
-Dusemultiplicity'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=define
useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='2.96 2731 (Red Hat Linux 7.2 2.96-108.1)',
gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lc -lcrypt -lutil
perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil
libc=/lib/libc-2.2.4.so, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
Locally applied patches:
ActivePerl Build 633
Built under linux
Compiled at Mar 24 2003 17:43:39
%ENV:
PERL5LIB="/dp/usr/cxp/perl/lib"
@INC:
/dp/usr/cxp/perl/lib/i686-linux-multi
/dp/usr/cxp/perl/lib
/usr/local/stow/perl-5.6.1-a633/lib/perl5/5.6.1/i686-linux-multi
/usr/local/stow/perl-5.6.1-a633/lib/perl5/5.6.1
/usr/local/stow/perl-5.6.1-a633/lib/perl5/site_perl/5.6.1/i686-linux-multi
/usr/local/stow/perl-5.6.1-a633/lib/perl5/site_perl/5.6.1
/usr/local/stow/perl-5.6.1-a633/lib/perl5/site_perl
/usr/local/lib/perl5/site_perl/5.6.1/i686-linux-multi
/usr/local/lib/perl5/site_perl/5.6.1
/usr/local/lib/perl5/site_perl
--
Any ideas on where to look next?
Cheers,
Ovid
=
Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
Re: Devel::Cover bug in ActiveState Perl for *Linux*
FYI: I've managed to replicate this error on another ActiveState Perl linux box. The Perl -V information is the same, but the module list is quite a bit smaller. The only common element that I can find is ActiveState. Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
Re: Devel::Cover bug in ActiveState Perl for *Linux*
--- Paul Johnson <[EMAIL PROTECTED]> wrote: > I think the key is that it is perl version 5.6.1. I can reproduce the > problem on a stock 5.6.1 on linux (well, hacked just enough to get it to > build). Hmmm ... I saw this *after* my second ActiveState email. > Actually, I wonder whether 5.6.1 should be supported or not. I think that 5.6.1 is widespread enough that you might lose much of your intended audience if it's not supported. I know that I currently have a project at work that involves code coverage stats, but this is part of our plan to migrate to 5.8.1. We don't *need* this information, but it would be very helpful. > In any case, thanks a lot for tracking this down. I'm sure it wasn't > trivial. Not a problem. Devel::Cover has been part of my plan for fixing some serious problems at work. I've been hoping to use to help us figure out how much old code we have so we can delete it and start refactoring from a cleaner code base. I'll dig some more and see if I can come up with a workaround. Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
Perl Core Tests
I was browsing through the Perl core tests and I saw that some tests in the t/uni/ directory used Test::More, but most other tests would explicitly 'print "ok 1\n"'. Is this to reduce the dependancy of the core tests on external modules (and if so, why does t/uni/ not follow the convention) or have they simply not been converted? Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
Devel::Cover and large test suites
Hi all, After much agony, I finally managed to get our test suite running with 5.8.1. Unfortunately, the suite of 15,000 tests takes about an hour to run. After it finished, Devel::Cover proceeded to use more and more memory until finally someone on our night crew killed the process. I'm wondering if coverage results are cumulative? If I have tests in four different directories, can I run the tests separately, specifying the same coverage db for each and thereby *gradually* accumulate this information? Are other workarounds available? Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
Re: Devel::Cover and reading docs :/
--- Ovid <[EMAIL PROTECTED]> wrote: > I'm wondering if coverage results are cumulative? If I have tests in four different > directories ... Of course they are, if the -merge option is on. I missed that. You may now return to your regularly scheduled programming. Whoops, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
When Good Practices Go Bad (was: re: Devel::Cover...)
--- Tony Bowden <[EMAIL PROTECTED]> wrote:
> We insist on a full regression test on checkin, so having the test suite
> take a long time to run puts people off making small changes. :(
>
> On one project a full regression test takes about 8 minutes, which is at
> least an order of magnitude longer than I'd like. I couldn't dream of
> having it take an hour!
Unfortunately, that's something we seem to be stuck with here. At my previous job, we
had one
test suit with a similar number of tests, but it took -- at most -- about 3 minutes to
run. The
problem is that test driven development started here before the current testing
craze. As a
result, my fellow programmers have some curious notions about testing. Amongst other
things, each
file is a package that has several TEST subroutines in it. These tend to have the
following
characteristics:
sub TEST__WE_CAN_ADD_FOO_TO_BAR
{
make_up_test_data();
add_test_data_to_database();
my $foo = function_to_test();
assert($foo, $some_made_up_val);
}
Now, before that function is run, we automatically have a "setup_test" function that
runs. After
that function runs, a "teardown_test" function runs (which typically does a rollback).
So we have to make up a bunch of dummy data, insert this data, test this data, and
roll back this
data FOR EVERY TEST. Further, because of cut-n-paste testing, much of the dummy data
that is
inserted has nothing to do with a particular test and therefore is useless overhead.
Not only
does this slow the test suite to a crawl (and this is with Oracle, no less), I've
asked some of my
fellow programmers if they see a problem with testing made-up data and all I get are
blank stares.
It's similar to why programmers should not do their own acceptance testing: two
minutes later
they send an email saying "yup, it does what I programmed it to do."
To make matters worse, I've also asked "have you ever considered testing the data that
you have in
production?"
The answer, from every programmer I've talked to, has been "how can we test the data
if we don't
know what it is?" The programmes working here haven't worked with any other way of
testing so it
never occurs to them that there might be another way.
This company is doing some great work, but sometimes I want to scream.
Cheers,
Ovid
=
Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
Re: Devel::Cover and large test suites
--- Andy Lester <[EMAIL PROTECTED]> wrote: > 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. Sorry Andy, I can't quite agree with you on this one. Technically, you're 100% correct. The reality, though, is that when I'm trying to convince other programmers that they want to run the entire test suite before they check things in, I don't want to see them wince when I say that. The suite that I mentioned that takes over an hour to run is for *one* of our projects. We have many projects. Guess what happens when someone changes code that's shared with all projects? We are talking about many hours of tests. Programmers who "just know" that there change didn't break anything are faced with the prospect of several hours of tests, just to find out that they broke a couple of things, need to go in and fix it and then run several *more* hours of tests. When they made a 15 minute change and are looking at a couple of workdays to get it moved into production, they skip the tests. And yes, we've been bit by this :) The way we're doing tests is simply foolish and we could experience some significant productivity gains if we were to improve the test performance. Of course, I think it's fair to point out that much of the performance is due to a poorly thought out testing strategy. If the tests were designed better, I'd have less room to complain about how long they take to run. Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
No more code coverage
--- Tels <[EMAIL PROTECTED]> wrote:
> Well, still it would be good to improve the speed of Devel::Cover, on my box
> (lowly 500 Mhz, yes, I could upgrade to 2 Ghz AMD or so :) a particulary
> project takes 33 minutes for one run... not exactly what I call "interactive"
> :)
Frankly, I think some major work could be done here. In an attempt to eliminate the
problem I
had, I wrote a quick program that recursed through directories and ran the tests that
it found
there. The core of the loop was something like this:
my $count = 1;
my $total = @test_dirs;
foreach my $dir (@test_dirs) {
printf "\nProcessing %3d out of %3d: $dir\n\n", $count, $total;
chdir $dir;
my $command = 'perl -MDevel::Cover=-db,/home/ovid/cover_db /usr/bin/rtk_test";
system($command);
$count++;
}
There were 92 test directories in @test_dirs. By the time I got to the fourth
directory, I had a
45 megabyte coverage database and the output of top was:
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
22348 cxp 18 0 1133M 1.1G 19280 R99.9 55.5 30:29 perl
Needless to say, I killed the tests. I've never dug into the internals of
Devel::Cover so I don't
know how easy it would be to fix this (and maybe there's something really silly that
I've
overlooked). Unless I get very lucky, I think the code coverage project here is dead.
Cheers,
Ovid
=
Silence is Evil http://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
Re: No more code coverage
--- Paul Johnson <[EMAIL PROTECTED]> wrote: > Initially I wanted something with few, or better yet no dependencies. I > also wanted something that required little or no work when I changed the > internal data structures. Well, SQLite fails the first and *might* fail on the second. On the other hand, it's ridiculously fast, is easy to install and I'd cheerfully vote for it! I'm trying to talk my boss into letting me poke into the internals of Devel::Cover more, but I doubt that will be approved. If it is, maybe I can work on this. Cheers, Ovid = Silence is Evil http://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
Re: No more code coverage
--- Tim Bunce <[EMAIL PROTECTED]> wrote: > > I'll look into SQLite. > > I'd caution against rushing in any particular direction without some > profiling information to back it up. > > Having said that, I'd strongly recommend switching to Storable first. > It did have problems but it's now very robust and far, far, faster > than Data::Dumper+eval. This small change would yield a big gain. > > The next step would be to get some profile information. There's > little point in doing that first as Data::Dumper+eval will dwarf > time spent elsewhere. It's not performance that's killing Devel::Cover when we run tests. It's that the data structure for the coverage data appears to be built in-memory and it's so huge that I run out of memory (and this is on a machine with a couple of gigs of RAM). If it's not the data structure being built but instead is the conversion to Data::Dumper format, then ignore what I say :) Cheers, Ovid ===== Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
Re: Recommendations for testing e-mail output
When I encounter something like this, I usually just temporarily override the
function/method that
actually sends the mail:
my $email_text;
my $mail_func = 'My::Mail::Module::send';
{
no warnings 'redefine';
local *$mail_func = sub { $email_text = shift };
}
ok($email_text, "$mail_func should be called called");
is($email_text, $test_text, '... and the email should match the sample text');
The above, of course, is probably not as complete as you might want for production
code, but it's
roughly how I would approach the situation.
Cheers,
Ovid
--- Mark Stosberg <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I'm looking at writing a test for an e-mail that's generated by Perl.
> I'm wondering about the best way to do this. Here are some possibilities
> I have considered:
>
> - use Test::Mail. While it's designed for the task, I'm not fond of the
> complexity of setting up an e-mail address which sends the input to
> a test script, which generates a log file that someone eventually
> sees.
>
> - Test the message at the moment before it's sent. For this I thought
> Test::AtRunTime might be a good choice. The output could be a
> sent to a logfile that some other test script output could remind
> me to read...or perhaps even open for me.
>
> - ??
>
> I'm curious to know what others are doing to address this that they have
> been satisfied with.
>
> Thanks!
>
=
Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
__
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/
Re: Phalanx
--- "Jeays, Mark" <[EMAIL PROTECTED]> wrote: > Hi, > > I'm writing on behalf of Ottawa Perl Mongers. At our last meeting, one of > our members gave us a quick introduction to the Phalanx project and its > goals. A number of the members were interested in the idea and we have been > looking for a group project. How would we go about getting involved? Can we > pick a module we're interested in? Do you think doing tests for a module > would be suitable for a group to take on? Is there a particular methodology > to be followed? 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? Cheers, Ovid ===== Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/
Re: reducing size of the Devel::Cover html report
--- Michael Carman <[EMAIL PROTECTED]> wrote: > Cosmetically, everything should look almost identical. Behind the scenes I've > pretty much gutted and rewritten everything. Most significantly, it no longer > requires (uses) the Template Toolkit. Out of curiosity, why did you remove Template Toolkit? Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
Re: Using environment variables to control long running tests (again)
--- Kate L Pugh <[EMAIL PROTECTED]> wrote: > This was discussed on this list back in June. I'm wanting to > implement it now and am wondering if Andrew's suggestion (below) has > been taken up by anyone. Is PERL_TEST_LONG what people here > generally > expect to be the right environment variable to set to enable > long-running tests? I don't know if something like that's been implemented or not, but I think it's something that should be implemented by the user and probably not be pushed into the core testing suite. Also, I would recommend something like PERL_SKIP_LONG_TESTS. By default, all tests should be run to prevent the user accidentally forget to run some tests. If any tests are skipped, it should be by the explicit instruction by the person running the test lest nasty surprises crop up. Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
Re: Perl Abstract/Concrete Syntax Tree
--- "Potozniak, Andrew" <[EMAIL PROTECTED]> wrote: > Hi, > > I was wondering if there was anything built in Perl (a Module) that > will take in a Perl file and parse that into an abstract or concrete > syntax > tree. I searched around cpan for a bit and couldn't find what I was > looking > for. If anyone is wondering what I'm talking about there is a nice > Java > package that Eclipse uses to create a tree for Java compilation that > I can > point you toward. Thanks for your time. > > ~~Andrew Andrew, I'm a bit confused. Eclipse is simply an IDE, so that doesn't help me understand what you're looking for. As for turning a file into a "syntax tree", what do you mean? Files are in many different formats. I can't imagine a single module handling CSV, XML, and binary JPEG files the same way. If you could be a bit more concrete in what you are looking for, we would be better prepared to help. Perhaps if you could send a code snippet of what you would *like* Perl to do (and specify the file format(s) that you want to work with). Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: JavaScript/Perl Question
--- Tony Bowden <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 27, 2004 at 10:37:48AM -0500, Potozniak, Andrew wrote:
> > To make a long story short I can not get access to the source of
> the bottom
> > frame through JavaScript because of an access denied error.
>
> This is a security feature in most browsers -
Andrew,
Hate to say it, but Tony's right. I've run into this before and the
problem is not insurmountable, but it means that you have to have your
app running on a server.
Instead of loading the page directly into the lower frame, you'll want
the lower frame to point to a Perl script that loads the page for you.
Imagine something like this:
use LWP::Simple;
use CGI ':standard';
my $url = param('url'); # and untaint it
my $page = get($url);# you might need the cookies, too
# hand-wave
# rewrite all of the links to point to this script
# hand-wave
print header, $page;
With this, you can serve JavaScript and the "outside" pages from the
same server, but it's much tougher than it looks. I had written a
Template Toolkit plugin that did much of this for me to allow me to
create framed sites without frames, but it was for my old job and I no
longer have the code :(
I should note that this is also a very error-prone way to do things.
Fixing all of the links is more difficult than it sounds, particularly
if they have "target" attributes.
Cheers,
Ovid
=
Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: "Default" test name?
--- Andy Lester <[EMAIL PROTECTED]> wrote: > 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. That's actually one of my pet peeves when writing tests. ok(...); # no test name provided, but you can provide one isa_ok(...); # you can provide a test name, but it can look silly # what's automatically appended to it. can_ok(...); # you can't provide a test name at all! These are minor nits, but they're nits just the same. My thought is that test names are for me, the programmer, and not the computer. Thus I, the programmer, should have full control over them to suit my needs/standards/etc. I have a very specific format that I like my test output to be in and taking away this control blows my format. I suppose I should eventually do something about that, but I guess it doesn't annoy me enough to find a patch laying around somewhere. Cheers, Ovid -- whose waiting for someone to say, "you must not have read perldoc $foo" :) ===== Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Testing Inline::C
Hi all, http://search.cpan.org/~ovid/AI-NeuralNet-Simple-0.02/ I've a problem in testing Inline::C. In the module AI::NeuralNet::Simple, I do some work allocating and deallocating memory and I've been bitten by a bug where I wasn't allocating memory properly for one of my arrays. It's fixed, but I have no idea how to write a test for that. I'm also rather unclear about how to test the C functions. I only have 18 tests for the module, but it needs heavy redesign internally (such as not using globals in C) and while testing through the Perl interface will catch bugs, it won't tell me where the bugs are. My C skills are a bit weak, so gentle explanations (even RTFMs) would be great. Cheers, Ovid = Silence is Evil http://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: Devel::Cover - require 5.8?
--- Paul Johnson <[EMAIL PROTECTED]> wrote: > I am considering dropping support for Perl 5.6 in Devel::Cover. > [snip] > I realise that some people, especially those in a corporate environment > may not be able to simply upgrade. That's the problem that I am facing at work. I see from glancing at the CPAN that you've not deleted the older versions of Devel::Cover, so at least people would have a fallback position, but I suspect that requiring 5.8+ would seriously hamper the adoption of Devel::Cover. Later this might be practical, but for now, I'd be concerned. So far, I've only convinced one team at my work is using Devel::Cover, but they're already using 5.8. Trying to get others to adopt it would be impossible without 5.6 support. Of course, if 5.8 meant that Devel::Cover used considerably less memory and I could actually use it with our largest test suite (which takes almost two hours to run), then I'll cheerfully encourage you :) Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: Devel::Cover - require 5.8?
--- Tels <[EMAIL PROTECTED]> wrote: > There is a time when you have to abandon old stuff and just use the modern > thing. I would be curious what the reason for v5.6 are - and if not most of > them are of the "we are to lazy to upgrade", "we don't want to", "it always > worked" etc :) Well, since you asked: There are several reasons why the upgrade from 5.6 to 5.8 hasn't happened yet. First, the team that I am working on has a quarter million lines of Perl code, and that's not counting the template layer. Given that there are many different teams, you can get an idea of the scale of software that we routinely work with. Ignoring the other teams for the moment, here are some of the problems that I personally ran into when trying to upgrade our software to 58. Please note that I am not attempting to justify *anything* that I am about to write. I am merely describing the state of the software as I found it when I started working here. 1. Many CPAN modules do not quite fit our requirements, so we have to subclass them or fork the code. There are very few CPAN modules that we have not done this to in one way or the other. When we upgraded to 58, many of those broke outright because they had been so radically altered. (In large part, this was often done because we used early versions of modules written years ago. We needed features that people hadn't even thought of back then.) 2. Hash ordering is now guaranteed to be random (unless you specify different compile time options to Perl, something I chose not to do). Many of our tests assume that hash order is deterministic -- which it appeared to be prior to 58 (remember, "not guaranteed to return in a particular order" is not the same as "non-deterministic"). I had to rewrite much of our test suite (which takes around two hours to run!) to find and fix all of these. 3. Extensive use of pseudo-hashes. 4. Internally, some source filters are used which automatically built prototypes for subs. They work well, but caused many strange problems. 5. Localizing tied arrays and hashes is broken in 5.8. We tie and localize %ENV. 6. Because of sloppy programming, many tests emitted warnings and a few failed intermittently. Given that I had to *guarantee* that none of those problems were caused by 58 and the test suite takes forever to run, I had to do this repeatedly to catch all intermittant failures and trap all warnings. This was a huge amount of programming time. 7. Of course, 58 is not binary compatible with 56, meaning many modules must be recompiled. This introduced plenty of other problems (don't even get me started about the module that now relies on Apache internals and thus cannot be used or required except in a mod_perl environment!!!) That list is not comprehensive, but it gives you an idea of what I faced. Here's the kicker: I've seen a lot of production Perl code and while you might cringe at some of the things I described, this is, hands down, the best production Perl I've had the joy to work with. Any shop that has a code base anywhere close to the size of ours could very well have a hell of a lot more work to do than I did. Further, given that larger code bases usually have more customer requests, upgrading to 58 might seem like a low-priority when a customer is dangling a hundred thousand dollars in front of you. Frankly, I was surprised I had support for the project. If I was not a new programmer who they were struggling to figure out what to do with, I probably would *not* have gotten approval. As it stands, I did the upgrade months ago and we're still waiting to install it. Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: Devel::Cover - require 5.8?
--- Nicholas Clark <[EMAIL PROTECTED]> wrote: > 5.8.2 and later have hashes that are deterministic until the data is > pathological. And the pathological checks kick in very late. Only 5.8.1 has > true random hashes (not 5.8.0) and even without compile time changes (IIRC) > you can always force deterministic hashes with environment variables. I didn't know that. Too late now :) (though I was developing with 5.8.1) > > 5. Localizing tied arrays and hashes is broken in 5.8. We tie and localize %ENV. > > I wasn't aware of this. Or at least, it doesn't ring a bell. Is perl5-porters > aware of this? Is this a known change in behaviour? >From perl58delta: The existing behaviour when localising tied arrays and hashes is wrong, and will be changed in a future release, so do not rely on the existing behaviour. See "Localising Tied Arrays and Hashes Is Broken". Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Duplicated code
As part of our refactoring project, we'd like to find duplicated code. Our hand-rolled scripts do a decent job, but could use a lot of work. Rather than do a lot of work, I'm curious to know if anyone knows of any tools already out there for that. Any suggestions? I'd be rather curious to hear about something that operates on the op-code level and can possibly cope with renamed variables as a result. Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: hoplite report for DBI : Part 2
--- stevan little <[EMAIL PROTECTED]> wrote: > I would also like to propose that we remove all -w flags, and convert > them to use the warnings pragma. Does that mean you don't want to support versions of Perl prior to 5.6? I would think that should be up to Tim. Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: hoplite report for DBI : Part 2
--- stevan little <[EMAIL PROTECTED]> wrote: > If this will break things prior to 5.6 then I reverse my proposal and > say that we should *not* use the warnings pragma and instead use the -w > flag. I always find it easier to roll back unwritten code :) Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Temporarily Overriding subs
Many times in test suites I don't want to mock up an entire class or package.
Instead, there are
only one or two target subroutines that I want to change. I get awfully tired of
doing the
following, though:
{
no warnings 'redefine';
my $message;
local *Foo::bar = sub { $message = shift };
...
}
That sucks because I constantly mistype things, or I find that I need to cache the
original sub
with my $sub = *Foo::bar{CODE} and I often forget the syntax the first time.
So I wrote a little module, Sub::Override, to do that for me. I can replace subs,
explicitly
restore them to their original value or just let the object fall out of scope and have
the subs
automatically restored. However, this seems like such an obvious little module that
*someone*
must have written it. Alas, I cannot find it on the CPAN. Is it out there and I
missed it, or is
this something I should upload?
Cheers,
Ovid
=
Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: Temporarily Overriding subs
--- Adrian Howard <[EMAIL PROTECTED]> wrote: > Hook::Lexwrap? > > It's what I normally use for this sort of thing, and you can > short-circuit the original method in a pre- wrapper. Ah, never knew about the short-circuiting. Thanks! Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Bizarre test failures in Devel::Cover
I've no idea why, but when I try to install Devel::Cover, I'm getting far more failed tests than there are tests. Below is the summary and my perl -v. Any ideas? I didn't see anything in the docs to indicate what the problem would be. Cheers, Ovid -- Failed TestStat Wstat Total Fail Failed List of Failed t/aalias.t 57 2184 38317.% 7-10952 t/aalias1.t 82 2213 26990.% 7-0 t/abranch_return_sub.t 68 2187 32170.% 7-10975 t/acond_and.t 111 2191 19746.% 7-11018 t/acond_branch.t482 2229 4624.4% 7-11389 t/acond_or.t137 2194 16018.% 7-11044 t/acond_xor.t57 2186 38359.% 7-10964 t/adefault_param.t 58 2186 37700.% 7-10965 t/adestroy.t 49 2183 44557.% 7-10944 t/adynamic_subs.t 115 2191 19056.% 7-11018 t/aeval1.t 89 2213 24875.% 7-7 t/afork.t51 2183 42813.% 7-10946 t/aif.t 74 2188 29570.% 7-10981 t/amodule1.t132 2218 16804.% 7-11160 t/amodule2.t132 2218 16804.% 7-11160 t/amodule_import.t 39 2182 55953.% 7-33 35-10934 t/aoverloaded.t 58 2237 38572.% 7-11218 t/askip.t54 2183 40438.% 7-35 37-10949 t/aspecial_blocks.t 51 2185 42860.% 7-10958 t/astatement.t 29 2181 75217.% 7-10924 t/at0.t 83 2189 26374.% 7-10990 t/at1.t 44 2185 49661.% 7-35 37-10951 t/at2.t 77 2188 28422.% 7-10984 t/atrivial.t 26 2181 83884.% 7-10921 t/auncoverable.t 64 2184 34137.% 7-10959 t/md5.t 26 2181 83884.% 7-10921 Failed 26/28 test scripts, 7.14% okay. 2086/2247 subtests failed, 7.17% okay. -- [0:xtnsdb1:~/temp/Devel-Cover-0.45/t] $ perl -v This is perl, v5.6.1 built for i686-linux-multi (with 1 registered patch, see perl -V for more detail) Copyright 1987-2001, Larry Wall Binary build 633 provided by ActiveState Corp. http://www.ActiveState.com Built 17:43:39 Mar 24 2003 = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: C/C++ White-Box Unit Testing and Test::More
--- Andrew Savige <[EMAIL PROTECTED]> wrote: > Has anyone ported a Test::More style framework to C/C++ or Java? > How do Perl5/Parrot white-box unit test their C code? For white box testing C code, I just use assert(). As for porting a Test::More style framework, I tried doing that with Python and was actually doing well with it, but I was shot down pretty quickly. xunit style testing, though it has limitations, is very powerful and people are quick to scoff at alternatives (at least from what I've experienced.) Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
xUnit vs. Test::More
--- Piers Cawley <[EMAIL PROTECTED]> wrote: > The xUnit style framework does a much better job of enforcing test > isolation than Test::More does (but you have to remember that what > Test::More thinks of as a test, xUnit thinks of as an assertion to be > used *in* a test). After working with xUnit style testing for almost a year, I definitely agree with this assessment. However, I think each style has its merits. With xUnit frameworks, each test will set up its data in the database, run through its asserts and then rollback the data. The setup and teardown methods ensure that each test is isolated from all other tests and you thus don't have accidental dependencies. The also impose a considerable overhead. At my current position, we've managed to get our test suite (xUnit style) running fast enough that it takes about 50 minutes to run. At my previous job, a comparable size test suite using Test::More took less than 5 minutes to run (I judge "comparable sized" by comparing Test::More tests to xUnit asserts.) Between the two, the 50 minute tests suite is probably more robust, but taking 10 times as long to run means that we've been bitten a few times by programmers who are in a hurry and don't run the full suite for a change that "can't break anything." The other concern I've had with our style of xUnit testing is that we're testing behavior, but not the actual data. With Test::More, we tested against a copy of the live database (when possible -- but this definitely caused some issues) and we sometimes caught data problems that xUnit style testing seems less likely to catch. The reason for this is quite simple: when you setup the data, you're setting up your *idea* of what the data should be. This might not match what your data actually is. Am I missing something fundamental? The long test times and the lack of real data testing are two weaknesses that I would like to correct in our current system, but I see how beneficial xUnit testing is, so I'm concerned about introducing "fixes" that weaken our testing strategy. How do others deal with this? Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: C/C++ White-Box Unit Testing and Test::More
--- Tony Bowden <[EMAIL PROTECTED]> wrote: > The big gain for me with Test::Class is inheritable tests. Subclasses > can ensure they still pass all their parent's tests, as well as all of > their own, without me having to copy all the tests, or set up a really > clumsy testing environment. And of course you get to refactor the test > suite quite nicely too so that it's really obvious what each test is > doing. I also like the thought of inheriting tests, but I know not everyone is fond of this idea. There was a moderately interesting discussion about this on Perlmonks: http://www.perlmonks.org/index.pl?node_id=294571 Cheers, Ovid = Silence is Evil http://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: C/C++ White-Box Unit Testing and Test::More
--- Andrew Pimlott <[EMAIL PROTECTED]> wrote: > Now I'm confused too. None of the Test::Unit examples I've seen use > "is", they use some form of assert. You were looking at Test::Class code, not Test::Unit code. Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Open Perl bugs should be closed?
In his latest Perl 5 Bug Summary, Robert Spier listed the following bugs. I seem to recall that patches were sent to perl-qa to resolve these. Were they not applied or were the bugs not closed? (Or were they not sent and I'm enjoying a touch too much wine here?) 30576 Test::More thinks "" eq undef in hash value 30584 Test::More is_deeply bug Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: [RFC] Test-Locally
--- Geoffrey Young <[EMAIL PROTECTED]> wrote:
> hi all...
>
> from the docs Hook::Lexwrap just seems to be way too much for testing.
Hi Geoff,
What an interesting coincidence. I recently came to the same conclusion, so I uploaded
Sub::Override to the CPAN a few days ago.
http://search.cpan.org/~ovid/Sub-Override-0.03/
Synopsis:
my $override = Sub::Override->new( foo => sub { 'overridden sub' } );
# use the new sub
$override->restore;
# original sub available
You can override multiple subs:
$override->replace('Some::sub1', sub { 'new data1' })
->replace('Some::sub2', sub { 'new data2' })
->replace('Some::sub3', sub { 'new data3' });
And you can let the overriding 'fall out of scope':
{
my $override = Sub::Override->new(some_sub => \&new_sub);
# new some_sub behavior
}
# old some_sub behavior
It has a few other features, too. If anyone likes it and has any feature requests,
please let me
know.
Cheers,
Ovid
=
Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: [RFC] Test-Locally
--- stevan little <[EMAIL PROTECTED]> wrote: > Geoff, > > This sounds like mock objects basically > (http://www.mockobjects.com/FrontPage.html), although maybe on a > smaller/more-directed scale. I do like the idea of building a mock > object repository of sorts, I am sure that would come in handy. > > Steve MockObjects are great, but sometimes you just want to replace one teeny, tiny little function that's making life miserable. Also, MockObjects are great if the interface is OO, but not if it's procedural. Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: [RFC] Test-Locally
--- chromatic <[EMAIL PROTECTED]> wrote: > Test::MockObject::Extends comes to mind. It's often what people want > instead of T::MO. Fortunately, they're in the same distribution. Sweet. I never noticed that one. That solves a niggling issue I've had with Test::MockObject. Thanks! Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: Test::Harness with modules that output to STDOUT
--- Peter Kay <[EMAIL PROTECTED]> wrote:
> Ok, what's the elegent way to ignore/dispose of the output the tested
> module produces?
What I do whenever this happens is to move the printing code to a subroutine or method
and
override that to capture the output. So if I have something like this:
sub Foo::_print {
print shift;
}
In my test, I have something like this:
my $_print;
*Foo::_print = sub { $_print = shift };
is($_print, $expected, "Foo::_print output the correct data");
This has several benefits. Not only do you not worry about how Test::Harness will
react, you also
have the ability to test the printed data, something which is frequently not done.
Also, I've
found that by refactoring such functionality into one subroutine, I later have a
convenient place
to alter the behavior, if necessary, rather than hunt through the code. I've found
this to be
very useful if I need to send the data to different destinations or add behavior such
as emailing
critical error messages or reports.
If you hate using typeglobs:
use Sub::Override; # disclaimer: I wrote it.
my $_print;
my $override = Sub::Override->new('Foo::_print' => sub { $_print = shift });
(You can later restore the subroutine, if needed)
Cheers,
Ovid
=
Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Specification based testing
I'm at work, so I've not had a chance to think too deeply about this, but here's an interesting node about specification-based testing using Test::LectroTest (http://search.cpan.org/~tmoertel/Test-LectroTest-0.2006/) http://www.perlmonks.org/index.pl?node_id=390737 It looks like food for thought. Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: Build Status of CPAN modules from ActiveState
--- Gabor Szabo <[EMAIL PROTECTED]> wrote: > On this page > http://aspn.activestate.com/ASPN/Downloads/ActivePerl/PPM/Repository > there are two links to the build status of various CPAN modules > using 5.6 and 5.8 respoectively. [snip] > The individual build results have their own separate files such as > > http://ppm.activestate.com/BuildStatus/5.8-windows/windows-5.8/Acme-1.111.txt Side note: Not all modules have build results. I have a couple of modules with failures, but since they don't list why, I have no way of resolving the problem. Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: Quality from the Beginning: Better Estimates
--- Mark Stosberg <[EMAIL PROTECTED]> wrote: > So, what resources are recommended to consult to make great > estimates? > What habits to develop? /me puts on his "economics" hat. It's widely reported that the majority of "large" software projects fail. I won't cite anything here as this is easy to google and verify that, at the least, large software projects are more *likely* to fail. Fred Brooks, in his classic book "Mythical Man Month" pointed out that communication does not scale well. As more resources are allocated to a project, communication needs increase. This was news to many in software management but any Econ 101 student should say "duh! That's the law of diminishing marginal returns!" If you're curious, you can read about this at http://www.cr1.dircon.co.uk/TB/2/dreturns.htm. Basically, the primary reason for the collapse of large projects tends to be search costs (the cost of acquiring information.) Few companies commit a million or more dollars to a project that doesn't at least *look* feasible. However, as the project progresses, A isn't aware that B doesn't know X and as a result, B doesn't tell C about it and C has no reason to even suspect that X is necessary. As a result, information does not flow freely and not having this information up front causes delays and cost overruns. XP, though not perfect (and not always appropriate for a given project), has clearly defined roles and a fairly easy to understand system of disseminating information. When done properly, developers really know what they need to know before they start writing code. If they don't know something, they know who to turn to get the information. So if you want projects to run successfully, always strive to minimize search costs. Stand-up meeting, iteration planning meetings, task cards and tests are some of the many tools that help with that. Foster a culture of information sharing through well-defined channels instead of the information hoarding (though often accidental) that we commonly see and your project has a much greater chance of success. Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/decency.html Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: Quality from the Beginning: Better Estimates
--- Ovid <[EMAIL PROTECTED]> wrote: > --- Mark Stosberg <[EMAIL PROTECTED]> wrote: > > So, what resources are recommended to consult to make great > > estimates? > > What habits to develop? And all that writing only to notice that I only peripherally touched on your question :) Whoops, Ovid = Silence is Evil http://users.easystreet.com/ovid/philosophy/decency.html Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: Test names vs. test comments
--- Andy Lester <[EMAIL PROTECTED]> wrote: > > Hmm ... I like this idea, though I confess that I don't like that > the comment is optional. > > There's no way to not make it optional. If you require that a > comment > be passed, then people will pass "comment" and leave it at that. Yes, I'm painfully aware of that. As with POD, traditional comments, test comments or anything else that is not absolutely required to get software to function, programmers (including me) will take shortcuts. Even if we don't skimp, they'll get overlooked in maintenance, rush to deadlines, etc. Only when comments *become* the programs they are supposed to document will this problem be solved (and programming will likely be much better for it.) Cheers, Ovid = Silence is Evil http://users.easystreet.com/ovid/philosophy/decency.html Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Test Failure Hooks
Is there is anything in the Test::* hierarchy that allows callbacks to be triggered on test failures? It would be nice to pass a sub that automatically dies on warnings, prints stack traces, cleans up temp files (or preserves them) or any of a number of things that I'd like to be able to handle. Someone's surely done this before, I just can't seem to find anything that's already implemented. Cheers, Ovid = Silence is Evil http://users.easystreet.com/ovid/philosophy/decency.html Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: Test label - contents
--- Tim Bunce <[EMAIL PROTECTED]> wrote:
> Changing the subject slightly, is there any guidance on what people
> should write in the name/comment/label?
>
> I ask because several times I've been puzzled by a test failure
> where the message printed is ambiguous. Compare these two:
>
> not ok 42 - is red
>
> not ok 42 - should be red
>
> The first isn't clear whether "is red" is what's expected or what's
> actually happened.>
Personally, I prefer a style where I had a "lead" test with a
left-justified comment and "dependent" tests with indented comments. I
prefer, when it's done, to produce a "flowing" narrative that explains
what *should* be going on from a developer standpoint.
ok 5 - Module->can('color_name')
ok 6 - ... and color_name() should croak if called with no arguments
ok 7 - ... or if it's passed something other than a 6 digit hex value
ok 7 - ... but it should return a human readable color name for the hex
value
That should give one an overview of what's happening and then if it's
not really clear, you can dig into the actual test to see the
implementation. It's more work than others wish to do, though. Many
programmers seem to be happy with "is red" and this seems to lead to a
greater need to actually read the test implementation (if not the
actual code.)
Cheers,
Ovid
=
Silence is Evil
http://users.easystreet.com/ovid/philosophy/decency.html
Ovid http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: Test Failure Hooks
--- Andy Lester <[EMAIL PROTECTED]> wrote: > Q&D way would be to confess. > > is( $nstooges, 3 ) or confess; Yes, that works, but when I am doing heavy development on a bunch of new code, it's nice to have generic hooks in place to handle such issues even if I don't know before hand which tests are going to fail. If this is not already implemented, can you point to the correct modules for which I would need to submit a patch? :) Cheers, Ovid = Silence is Evil http://users.easystreet.com/ovid/philosophy/decency.html Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Test::Cookbook?
I thought some of you might find this of interest and then I realized
that a Test::Cookbook might be useful. Here's a problem I recently
faced and how I solved it:
Problem:
POD is incomplete in a module but you still want to test POD coverage
with something like Test::Pod::Coverage::all_pod_coverage_ok().
Solution:
Have a hash of modules to skip and use TPC's all_modules() function to
ensure you don't miss new modules.
use strict;
use Test::More;
eval "use Test::Pod::Coverage 0.08";
plan skip_all => "Test::Pod::Coverage required for testing POD
coverage" if $@;
my %TODO = map { $_ => 1 } @modules_with_incomplete_pod;
my @modules = Test::Pod::Coverage::all_modules();
plan tests => scalar @modules;
foreach my $module (@modules) {
if (exists $TODO{$module}) {
TODO: {
local $TODO = "Known incomplete POD for $module";
pod_coverage_ok($module);
};
}
else {
pod_coverage_ok($module);
}
}
Discussion.
Actually, I'd rather have a Test::Cookbook discussion. You can see the
intent of the above code. It's not perfect (and I'm open to
suggestions for improvement), but it's something that is not
immediately obvious to someone who just started testing.
Cheers,
Ovid
=
Silence is Evil
http://users.easystreet.com/ovid/philosophy/decency.html
Ovid http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: New qa.perl.org updates
Two comments: I would add Test::MockModule to the test modules. I've stopped using my Sub::Override since I encountered this very useful tool. On the test guidelines, perhaps there should be an "or die " recommendation after "use_ok". Life gets pretty miserable if that fails but many subsequent tests pass and testa # 217 and beyond fail because the module didn't load properly. You can spend hours debugging because you didn't see the "use_ok" failure at the top. (I speak from extremely painful personal experience on this.) Cheers, Ovid --- Andy Lester <[EMAIL PROTECTED]> wrote: > http://qa.perl.org/testing-guidelines.html is updated. So is > http://qa.perl.org/test-modules.html, with new modules and some > reorganization. > > xoxo, > Andy > > > -- > Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance > ===== Silence is Evil http://users.easystreet.com/ovid/philosophy/decency.html Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: New qa.perl.org updates
--- Andy Lester <[EMAIL PROTECTED]> wrote: > > Patches, please. s/html$/pod/ in the URL for the source. Sorry. I should have gotten these out sooner. I was sidetracked. I've attached patches to add Test::MockModule to the module list and to add the "use_ok() or die" wording to the testing guidelines. I will confess that I was not entirely happy with my wording on the latter. Cheers, Ovid = Silence is Evil http://users.easystreet.com/ovid/philosophy/decency.html Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ testing-guidelines.pod.diff Description: testing-guidelines.pod.diff test-modules.pod.diff Description: test-modules.pod.diff
Test::Builder versus Unicode
Hi all,
The following code:
use utf8;
use diagnostics;
BEGIN {binmode STDOUT, ':utf8';}
use Test::More tests => 1;
# those are smart quotes
diag "This is a \x{201c}test\x{201d}";
ok 1;
Produces the following error message:
1..1
Wide character in print at /usr/local/lib/perl5/5.8.5/Test/Builder.pm
line 1005 (#1)
(W utf8) Perl met a wide character (>255) when it wasn't expecting
one. This warning is by default on for I/O (like print). The
easiest
way to quiet this warning is simply to add the :utf8 layer to the
output, e.g. binmode STDOUT, ':utf8'. Another way to turn off the
warning is to add no warnings 'utf8'; but that is often closer to
cheating. In general, you are supposed to explicitly mark the
filehandle with an encoding, see open and perlfunc/binmode.
# This is a “test”
ok 1
And looking at line 1005:
sub _print_diag {
my $self = shift;
local($\, $", $,) = (undef, ' ', '');
my $fh = $self->todo ? $self->todo_output : $self->failure_output;
print $fh @_; # here there be smart quotes
}
There are a few strange paths in the code which could be causing this
(I'm wondering about the autoflush), but I was wondering if anyone has
seen this and knows how to cope with it? As you can see, I've tried
that standard binmode ':utf8' and using utf8, but to no avail.
Cheers,
Ovid
=
Silence is Evil
http://users.easystreet.com/ovid/philosophy/decency.html
Ovid http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: Test::Builder versus Unicode
--- Nicholas Clark <[EMAIL PROTECTED]> wrote: > On Wed, Dec 22, 2004 at 10:26:02AM -0800, David Wheeler wrote: > > 1. Perl gets smarter about duping file handles, so that the dupes > get > > the same i/o layer settings as the handles they dupe. > > Changing this going forwards doesn't change any of the installed > perls out there in the wild. So far, given that this problem has only surfaced in relation to Unicode, I can't say I'm overly concerned about fixing it on versions of Perl where Unicode is already known to be broken. Of course, as soon as someone comes up with other layers for which we have a definite problem, I'll shut up. Cheers, Ovid = Silence is Evil http://users.easystreet.com/ovid/philosophy/decency.html Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Fwd: Out of Office Contact
OK, everyone send Mr. Cowgilll a polite message letting him know that, in the future, he needs to not send these messages to mailing lists. He'll feel really bad about his poor etiquette and we can say "only Cowgills get the blues." Ooh, that was awful, awful, awful. Never let me near a pun again, please. Cheers, Ovid --- [EMAIL PROTECTED] wrote: > Subject: Out of Office Contact > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Date: Wed, 22 Dec 2004 19:55:11 + > > I will be out of the office starting 21/12/2004 and will not return > until > 31/12/2004. > > I am away today. Talk to Simon Fairey if you have any urgent issues. = Silence is Evil http://users.easystreet.com/ovid/philosophy/decency.html Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
is_deeply hangs
(Aargh! This time I'll send this from the correct email address.)
Hi all,
I didn't find that this is a known issue reported somewhere so I
thought I would post it here.
This program hangs when it hits is_deeply. I eventually get an "out of
memory" error.
#!/usr/local/bin/perl
use AI::Prolog::Parser;
use AI::Prolog::Term;
use AI::Prolog::Engine;
use Test::More qw/no_plan/;
use Test::Differences;
use Clone qw/clone/;
my $database = AI::Prolog::Parser->consult(<<'END_PROLOG');
append([], X, X).
append([W|X],Y,[W|Z]) :- append(X,Y,Z).
END_PROLOG
my $parser = AI::Prolog::Parser->new("append([a],[b,c,d],Z).");
my $query = AI::Prolog::Term->new($parser);
my $engine = AI::Prolog::Engine->new($query,$database);
my $cloned_db = clone($database);
eq_or_diff $cloned_db, $database, 'eq_or_diff says they are the
same';
is_deeply $cloned_db, $database, '... but this hangs';
AI::Prolog is not yet on the CPAN, so if someone want's to test this,
they can grab it from
http://users.easystreet.com/ovid/downloads/AI-Prolog-0.01.tar.gz
I didn't do too much research into this as eq_or_diff() solves my
problem, but we appear to have an infinit loop in Test::More::eq_hash.
Cheers,
Ovid
=
If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
is_deeply hangs
Hi all,
I didn't find that this is a known issue reported somewhere so I
thought I would post it here.
This program hangs when it hits is_deeply. I eventually get an "out of
memory" error.
#!/usr/local/bin/perl
use AI::Prolog::Parser;
use AI::Prolog::Term;
use AI::Prolog::Engine;
use Test::More qw/no_plan/;
use Test::Differences;
use Clone qw/clone/;
my $database = AI::Prolog::Parser->consult(<<'END_PROLOG');
append([], X, X).
append([W|X],Y,[W|Z]) :- append(X,Y,Z).
END_PROLOG
my $parser = AI::Prolog::Parser->new("append([a],[b,c,d],Z).");
my $query = AI::Prolog::Term->new($parser);
my $engine = AI::Prolog::Engine->new($query,$database);
my $cloned_db = clone($database);
eq_or_diff $cloned_db, $database, 'eq_or_diff says they are the
same';
is_deeply $cloned_db, $database, '... but this hangs';
AI::Prolog is not yet on the CPAN, so if someone want's to test this,
they can grab it from
http://users.easystreet.com/ovid/downloads/AI-Prolog-0.01.tar.gz
I didn't do too much research into this as eq_or_diff() solves my
problem, but we appear to have an infinit loop in Test::More::eq_hash.
Cheers,
Ovid
=
If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Overriding Test::Builder::ok
Per this message from Schwern
(http://www.mail-archive.com/perl-qa@perl.org/msg03122.html) on how to
trigger custom behavior for individual tests:
For individual failures, put a wrapper around
Test::Builder->ok(). Use Hook::LexWrap, Sub::Uplevel
or Aspects to preserve the call stack.
Well, OK. So I tried it:
use Test::More qw/no_plan/;
use Test::Builder;
use Hook::LexWrap;
use Data::Dumper;
wrap Test::Builder::ok
pre => sub { die Dumper [EMAIL PROTECTED] };
ok 1, 'should be good';
is 2, 3, 'is 2 3 should be bad';
is 'foo', 'foo', 'and this should be good';
I must be missing something because that didn't die. It quite happily
ran the tests. Can someone please tell me what I am missing?
Cheers,
Ovid
=
If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Pattern patch for prove
Hi all,
Long before prove came along, I used a program named "grind" to manage
my test suites. One thing that grind had that prove does not was the
ability to specify *which* tests to run. grind did it via shell
expansion and that was terrible. Andy sensibly did not include that in
prove.
I want that back, however, so I've included a patch that allows prove
to run tests based upon a pattern. So if you're heavily focused on
your "Customer" behavior and you want to just run those tests:
prove -p '*cust*' t/
prove --pattern='*cust*' t/
Patterns must be valid Perl regular expressions and prove will die if
an invalid pattern is supplied.
Comments welcome.
Cheers,
Ovid
=
If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/--- prove 2005-01-24 13:30:25.060298520 -0800
+++ prove.new 2005-01-24 13:31:05.120208488 -0800
@@ -11,7 +11,7 @@
use File::Spec;
use vars qw( $VERSION );
-$VERSION = "1.04";
+$VERSION = "1.05";
my @ext = ();
my $shuffle = 0;
@@ -21,6 +21,7 @@
my $recurse = 0;
my @includes = ();
my @switches = ();
+my $pattern;
# Allow cuddling the paths with the -I
@ARGV = map { /^(-I)(.+)/ ? ($1,$2) : $_ } @ARGV;
@@ -39,6 +40,7 @@
'H|man' => sub {pod2usage({-verbose => 2, -input => \*DATA}); exit},
'I=s@' => [EMAIL PROTECTED],
'l|lib' => \$lib,
+'p|pattern=s' => \$pattern,
'r|recurse' => \$recurse,
's|shuffle' => \$shuffle,
't' => sub { unshift @switches, "-t" }, # Always want -t up front
@@ -48,6 +50,11 @@
'ext=s@'=> [EMAIL PROTECTED],
) or exit 1;
+if ($pattern) {
+eval {"" =~ /$pattern/};
+die "Bad pattern ($pattern): $@" if $@;
+}
+
$ENV{TEST_VERBOSE} = 1 if $Test::Harness::verbose;
# Build up extensions regex
@@ -80,6 +87,7 @@
my @tests;
@ARGV = File::Spec->curdir unless @ARGV;
push( @tests, -d $_ ? all_in( $_ ) : $_ ) for map { glob } @ARGV;
[EMAIL PROTECTED] = grep /$pattern/ => @tests if $pattern;
if ( @tests ) {
shuffle(@tests) if $shuffle;
@@ -178,6 +186,7 @@
-H, --man Longer manpage for prove
-I Add libraries to @INC, as Perl's -I
-l, --lib Add lib to the path for your tests.
+-p, --pattern Only run tests whose filenames match the specified pattern.
-r, --recurse Recursively descend into directories.
-s, --shuffle Run the tests in a random order.
-T Enable tainting checks
@@ -274,6 +283,14 @@
Add C to @INC. Equivalent to C<-Ilib>.
+=head2 -p, --pattern
+
+Only run tests whose filenames match a given regular expression. This regular
+expression must be a valid Perl regular expression or F will die.
+
+ prove -p 'cust.*\.t' t/
+ prove --pattern='cust.*\.t' t/
+
=head2 -r, --recurse
Descends into subdirectories of any directories specified, looking for tests.
Re: Test::Unit, ::Class, or ::Inline?
Hi Ian, Test::Unit was a nice idea, but it's been abandoned. Test::Inline seems nice, but it doesn't give you the full benefits of Test::Class (convenient setup, teardown, inheritance, etc.). Test::Class is great. I'm quite happy with it. If you're more comfortable with XUnit style testing, this is the way to go. However, read the docs for caveats. Test::More is also good if you're doing smaller projects. All of my CPAN modules now require Test::More. It's very easy to use and you can get up to speed faster with Test::More than most of the other testing tools (besides Test::Simple). Cheers, Ovid --- Ian Langworth <[EMAIL PROTECTED]> wrote: > I'm taking a software development class this semester which will > involve > writing extensive object-oriented code. My partner and I are trying > to > decide whether to use Test::Unit, ::Class, or ::Inline for our test > scripts. > > I can see the advantages of Test::Class in terms of object heirarchy, > > but I really like the idea of having my tests right along with the > methods when using Test::Inline. (The latter would be great when > presenting our code to the class.) > > Thoughts? > > -- > Ian Langworth > Project Guerrilla > Northeastern University > College of Computer and Information Science > > = If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Overriding Test::Builder::ok
--- Ovid <[EMAIL PROTECTED]> wrote:
> Per this message from Schwern
> (http://www.mail-archive.com/perl-qa@perl.org/msg03122.html) on how
> to
> trigger custom behavior for individual tests:
>
> For individual failures, put a wrapper around
> Test::Builder->ok(). Use Hook::LexWrap, Sub::Uplevel
> or Aspects to preserve the call stack.
>
> Well, OK. So I tried it:
>
> use Test::More qw/no_plan/;
> use Test::Builder;
> use Hook::LexWrap;
> use Data::Dumper;
>
> wrap Test::Builder::ok
> pre => sub { die Dumper [EMAIL PROTECTED] };
>
> ok 1, 'should be good';
> is 2, 3, 'is 2 3 should be bad';
> is 'foo', 'foo', 'and this should be good';
>
> I must be missing something because that didn't die. It quite
> happily
> ran the tests. Can someone please tell me what I am missing?
>
> Cheers,
> Ovid
>
> =
> If this message is a response to a question on a mailing list, please
> send
> follow up questions to the list.
>
> Web Programming with Perl --
> http://users.easystreet.com/ovid/cgi_course/
>
=
If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Overriding Test::Builder::ok (Warnocked?)
Ack! Sorry for the slippery fingers, folks. That last message should
actually have had some content to go with the quoting :/
OK, I can see that this one might have been Warnocked, but I can't see
how the prove pattern patch
(http://www.nntp.perl.org/group/perl.qa/3477) would be. I'd love to
see the latter in prove and not being able to override
Test::Builder->ok is giving me fits!
Cheers,
Ovid
--- Ovid <[EMAIL PROTECTED]> wrote:
>
> --- Ovid <[EMAIL PROTECTED]> wrote:
>
> > Per this message from Schwern
> > (http://www.mail-archive.com/perl-qa@perl.org/msg03122.html) on how
> > to
> > trigger custom behavior for individual tests:
> >
> > For individual failures, put a wrapper around
> > Test::Builder->ok(). Use Hook::LexWrap, Sub::Uplevel
> > or Aspects to preserve the call stack.
> >
> > Well, OK. So I tried it:
> >
> > use Test::More qw/no_plan/;
> > use Test::Builder;
> > use Hook::LexWrap;
> > use Data::Dumper;
> >
> > wrap Test::Builder::ok
> > pre => sub { die Dumper [EMAIL PROTECTED] };
> >
> > ok 1, 'should be good';
> > is 2, 3, 'is 2 3 should be bad';
> > is 'foo', 'foo', 'and this should be good';
> >
> > I must be missing something because that didn't die. It quite
> > happily
> > ran the tests. Can someone please tell me what I am missing?
> >
> > Cheers,
> > Ovid
> >
> > =
> > If this message is a response to a question on a mailing list,
> please
> > send
> > follow up questions to the list.
> >
> > Web Programming with Perl --
> > http://users.easystreet.com/ovid/cgi_course/
> >
>
>
> =
> If this message is a response to a question on a mailing list, please
> send
> follow up questions to the list.
>
> Web Programming with Perl --
> http://users.easystreet.com/ovid/cgi_course/
>
=
If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Overriding Test::Builder::ok (Warnocked?)
--- Andy Lester <[EMAIL PROTECTED]> wrote: > My concerns upon reading it: Perl-style regexes flies in the face of > standard globbing thoughts. Also, can we do it with core modules > only? A. It's documented that it's using Perl-style regexes. By using those, you don't have to worry about how different platforms handle globbing. By using Perl, you are once again platform independant. B. What do you mean, core modules only? I don't understand. Supplying a pattern to specify which test files to run is entirely optional and merely a useful aid in development. Is there something I am missing here? Cheers, Ovid = If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Test::Unit, ::Class, or ::Inline?
--- [EMAIL PROTECTED] wrote: > My main gripe is that the infrastructure for it is less OO friendly. > The example with the HTML output was awesome..until i looked at how > it was done. The inability to get a data structure back for the test > results is very, very frustrating. Well, I think there's going to be some movement on that front soon. The problem is not with Test::More. It's with Test::Harness. Using Test::Harness::Straps will get you partway there. Curiously, I posted an example today: http://www.perlmonks.org/index.pl?node_id=425356 In that example, your test output is in color. Passing tests are in green and failing tests are in red. Further discussion is at http://use.perl.org/~Ovid/journal/22899. Cheers, Ovid = If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: [PATCH Test::Harness::Straps] Add Diagnostic Output to Straps Results
--- chromatic <[EMAIL PROTECTED]> wrote:
> (and displaying better diagnostics on success or failure), here's a
> small patch to Test::Harness::Straps to collect the diagnostic
> information currently dumped to STDERR and to store it in the test
> data structure for Straps users to collect:
OK, I have to admit that I'm rather confused by this patch.
This line:
> +elsif ($result{number} and my $extra = $self->_is_extra_line(
> $line ))
Always fails to collect the data I need because $result{number} is
false when the extra data is being accumulated. Thus, I changed it to:
elsif (!$result{number} and my $extra = $self->_is_extra_line($line))
And this sub:
> +sub _is_extra_line
> +{
> +my ($self, $line, $test) = @_;
> +return if index( $line, '# Looks like you failed' ) == 0;
> +$line =~ s/^#//;
> +return $line;
> +}
Doesn't need the $test and I needed the "got/expected" information,
leaving me with:
sub _is_extra_line {
my ($self, $line) = @_;
return unless '#' eq substr $line, 0, 1;
$line = substr $line, 1;
return $line;
}
And my colored test output now looks like this:
* File 'sometest.t'
* Expected 4 / Seen 4 / Okay 3 / Failed 1
ok1 - a good test
ok2 - useless, but still a good test
* not ok3 - and this is a forced failure
* Failed test (sometest.t at line 8)
* got: '2'
* expected: '3'
ok4 - and this one is just obvious
Looks like you failed 1 tests of 4.
With the caveat that the asterisks at the front of the lines don't
really exist, but those lines are the ones that are colored bold red in
my output.
The rest of the patch was fine and I thank you very much!
Cheers,
Ovid
=
If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: [PATCH Test::Harness::Straps] Add Diagnostic Output to Straps Results
--- Ovid <[EMAIL PROTECTED]> wrote:
> > +elsif ($result{number} and my $extra = $self->_is_extra_line(
> > $line ))
>
> Always fails to collect the data I need because $result{number} is
> false when the extra data is being accumulated. Thus, I changed it
> to:
>
> elsif (!$result{number} and my $extra =
> $self->_is_extra_line($line))
And this is confusing me because the next line actually uses the
$result{number} but the code still works.
elsif (!$result{number} and my $extra = $self->_is_extra_line(
$line )) {
my $test = $totals->{details}[$result{number} - 1];
Weird.
Cheers,
Ovid
=
If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: [problem solved] Add Diagnostic Output to Straps Results
--- Ovid <[EMAIL PROTECTED]> wrote:
> And this is confusing me because the next line actually uses the
> $result{number} but the code still works.
>
> elsif (!$result{number} and my $extra = $self->_is_extra_line(
> $line )) {
> my $test = $totals->{details}[$result{number} - 1];
OK, OK, OK, I'll shut already and stop spamming you people :)
The reason that snippet worked is a bit of blind luck on my part. I
started thinking about this and realized that the details array must
keep test information in order. Thus, "$result{number} - 1" worked out
to "-1" when $result{number} wasn't defined, thus pointing me at the
last (and correct) element in the array :)
Cheers,
Ovid
=
If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: [PATCH Test::Harness::Straps] Add Diagnostic Output to Straps Results
--- chromatic <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-01-26 at 18:51 -0800, Ovid wrote:
> Odd. I think the problem was in looking for undefined values; at
> least,
> I remember ending up with that while writing the patch and running
> the
> Test::Harness tests.
Perhaps we have something else different on our systems, but when I'm
processing "extra" lines, $result{number} is false.
At first, it looked to me like $result{number} could *never* be true,
but then I saw the beginning of the long if/else block:
my %result = ();
$self->{line}++;
my $type;
if ( $self->_is_test($line, \%result) ) {
_is_test has the nasty side effect of altering %result and may change
subsequent conditionals. However, on subsequent lines which may have
the extra data, %result never has a number set, thus ! $result{$number}
is true when trying to capture extra data.
> I don't understand. These aren't equivalent. Mine should never
> exclude
> the expected and received lines, only the file-at-a-time summary
> diagnostics.
Your code was fine. I have no idea what I was talking about.
Cheers,
Ovid
=
If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Test names/comments/whatever?
Has there been any final decision as to what to call test names? There was quite a bit of discussion, but I don't recall the resolution. Cheers, Ovid = If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Test names/comments/whatever?
--- chromatic <[EMAIL PROTECTED]> wrote: > Alternately, encourage Andy to adopt some patch to > Test::Harness::Straps > that enables collecting that diagnostic information somehow and use > an alternate harness that displays test comments. Let me second that one! Of course, Andy's already made it clear that he doesn't have a lot of time, but I still don't mind kicking 'im. :) Cheers, Ovid = If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Test names/comments/whatever?
--- chromatic <[EMAIL PROTECTED]> wrote: > It's a patch to Test::Harness::Straps, the documentation of which > disclaims backwards compatibility. I'd like it to work on Windows so > as > to avoid people complaining if it doesn't, but I'm just saying that > 1) I > don't feel any particular guilt about suggesting a change to the > interface and 2) I suggested a change to the interface, with code and > tests and stuff. I have no problem with this. Is anyone even using THS? If anything, I suspect there are a tiny handful of people who have played with it, but haven't really used it since it's not as useful as it could be. Once it's made useful, it's a whole 'nuther ball game :) Cheers, Ovid = If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Test comments
What follows are the notes I have from someone else regarding the name "comment" for what was previously considered the "label." It's actually rather important that I have an answer for this, but I really can't go into more detail (sorry). Cheers, Ovid > It's been settled. It's officially a "test comment." Both Schwern and > Andy Lester have agreed and since they're the maintainers, that's good > enough for me. It makes good enough sense when you're dealing with the call to the test: ok($blah, "This is a test comment"); But it makes explaining the TAP format a pain. The "test comment" is everything after the test number or "ok" and before the # comment marker or end of the line. So, what's everything after the # comment marker? The other comment? It's a significant difference, too, because: ok 1 # skip ok 1 - blah, blah, blah # skip are skips (they have "skip" marked by the # comment marker), while: ok 1 skip ok 1 - skip aren't skips, they're just tests that happen to have "skip" as their name/label/identifier/whatever. = If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Test comments
--- Andy Lester <[EMAIL PROTECTED]> wrote: > On Mon, Feb 14, 2005 at 09:48:39AM -0800, Ovid > ([EMAIL PROTECTED]) wrote: > > It's actually rather important that I have an answer for this, but > I > > really can't go into more detail (sorry). > > It's a comment. There's more than one thing being defined as a comment: > But it makes explaining the TAP format a pain. The "test comment" is > everything after the test number or "ok" and before the # comment > marker or end of the line. So, what's everything after the # comment > marker? The other comment? It's a significant difference, too. Is this not correct? Where is the TAP protocol documented? Cheers, Ovid = If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Test comments
--- chromatic <[EMAIL PROTECTED]> wrote: > Can you tell I'm wearing my editor's hat? Awfully big hat :) = If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: TestSimple/More/Builder in JavaScript
David,
Great work!
> * I have made no decisions as to where to output test results,
> diagnostics, etc. Currently, they're simply output to
> document.write().
Output them to a Results object which, by default, sends the output to
document.write() but allows the user to redirect the output. For
example, it might be nice to have test results pop up in a separate
window while the main page loads.
> * Skip and Todo tests currently don't work because named blocks
> (e.g.,
> SKIP: and TODO:) are lexical in JavaScript. Therefore I cannot get at
How about:
if (some_condition) {
// do your tests
}
else {
skip(number_of_tests)
}
And:
while(todo(4)) { // sets an internal todo counter
// each test automagically decrements the todo counter
// ... but this should be transparent to the test code
}
> that I can tell). It might be that I need to just pass function
> references to skip() and todo(), instead. This is a rather different
> interface than that supported by Test::More, but it might work.
> Thoughts?
Will this screw up a stack trace? Also, while javascript doesn't have
the Perl concept of context, are there any scoping issues this might
cause problems with? Will passing a function reference have any chance
of altering the behavior of the code (it would in Perl).
> * Is there threading in JavaScript?
Used to be "no", but I'm not sure about the latest versions.
Cheers,
Ovid
--
If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: TestSimple/More/Builder in JavaScript
--- Michael G Schwern <[EMAIL PROTECTED]> wrote: > This > > is because there is no END block to grab on to in JavaScript. > > Could object destruction be used somehow? It's my understanding that the Ecmascript standard leaves garbage collection up to the implementation. I suspect this means we can't be sure exactly when an object is destroyed, though whether or not this has any bearing on David's problem is not clear to me. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: RFC - Class::Agreement
--- Ian Langworth <[EMAIL PROTECTED]> wrote: > I'm working on a new module, Class::Agreement, and I've started by > writing the documentation. If anyone has a few minutes, I'd like some > feedback as to whether my descriptions of the concepts make sense and > if you like the syntax. > > HTML: http://reliant.langworth.com/~ian/Class-Agreement.html > > POD: http://reliant.langworth.com/~ian/Class-Agreement.pod Hi Ian, In discussing the benefits, I didn't think you made a strong argument. However, in reading the page your docs points to, I think the argument can be improved with this: Precondition violations mean that the client is in error. Postcondition violations means that the supplier is incorrect. I also noticed you didn't make a comparison to Class::Contract. I think something explicit would be useful. You did write "Class::Agreement is also the only implementation in any language to blame failed contracts correctly", but I don't know what that means. I also note that the link you point us to after that comment is a citation, not something I can actually read. Other than that, it looks interesting. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: RFC - Class::Agreement
--- Ian Langworth <[EMAIL PROTECTED]> wrote: > Reflecting upon this, I'm not even sure why I'd want argument > modification as a feature. (Maybe I still had Hook::LexWrap on the > brain.) I might just take this out. I vote for taking it out. I view contracts to be similar to exceptions in one respect: when implemented properly, removing them from the code should not affect the normal operation of the code (sweeping a few things under the rug there). Thus, argument modification is a no-no. Some might argue against the bondage and discipline, but they're probably not going to be using Class::Agreement anyway :) > Class::Agreement's contracts should be > nearly as light as putting "die unless" in your methods. What? I had no idea. Was that in the docs and I overlooked it? To me, this is probably one of the strongest features of Class::Agreement and should definitely be hyped. Many aren't going to use Class::Contract due to the performance hit. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Fwd: [EMAIL PROTECTED]: Re: fixing is_deeply]
--- Piers Cawley <[EMAIL PROTECTED]> wrote: > I've always thought of C as being about the 'shape' of a > data > structure. When you think of things in this way, then it seems > obvious that given > > $a = [], $b = [], $c = [] > > then [$a, $a] and [$b, $c] have substantially different shapes. That's not obvious to me. When I look at that, I ultimately see this *shape* for each: "[[],[]]". In other words, I'm just looking for what data is arranged in what type of data structure. I'm not really considering how that structure might mutate given that someone comes along later and changes one of the values. I'd write a test for that. Heck, if we're going to consider that, why would this pass? my $a = [1,2,3]; my $b = [1,2,3]; is_deeply $a, $b, '...'; is_deeply $a, $a, '...'; That should pass nicely, but start shoving those array refs in other array refs and things fail? I don't see why. The argument seems to be that when we have [$a, $a] and [$b, $c], changing the value of $a in the first changes the value of the other $a and therefore the two array refs are not *functionally* equivalent. I want to know if the *data* are the same for a given test (which I like to think of as a snapshot in time). Whether or not the *behaviors* are the same is the reason I write more than one test. (Yes, I know that some might consider wether or not the references refer to the same area of memory as important. If so, don't use is_deeply. Perhaps we should have another test function?) So, just for the sake of argument, imagine I write a class where I periodically returns array refs to the user. I do this by building them every time they're called. Later, I realize that my methods are deterministic so I start caching results and returning them instead of rebuilding the array each time. I'm expecting my test suite to still continue working but under this proposed idea, it could be a nightmare for me to debug. Heck, when I print out the arrays with Data::Dumper, I'll see the same values and be mystified why they're not equivalent. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Fwd: [EMAIL PROTECTED]: Re: fixing is_deeply]
--- demerphq <[EMAIL PROTECTED]> wrote: > You are playing on some TV gameshow. You've won the big prize: a > house. Now the thing is that the presenter gives you a choice of two > envelopes. Both contain two house addresses. However one contains the > same address twice and the other contains two seperate addresses. > > The folks that argue that [$x,$x] is no different from [$x,$y] would > say that it doesnt matter which envelope you choose as there is no > difference. Those of use saying that [$x,$x] is different from > [$x,$y] > would suggest the opposite. Yves, With all due respect, if we're going to come up with contrived examples to show one empty array ref is not the same as another empty array ref, I could counter by coming up with an example where the behavior of *my* code is not dependant on this. The point is, it's not the case that your suggestion is wrong or that the current implementation is wrong. What you have correctly pointed out is that there is a limitation in the current implementation of is_deeply and there's a reasonable argument a different implementation. In short, I think most agree that we're talking about two separate things and that neither is wrong, so if someone wants to pitch a solution rather than continue a long email chain, I'm sure we'd be grateful :) Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: AnnoCPAN and a wiki POD idea
--- Ivan Tubert-Brohman <[EMAIL PROTECTED]> wrote: > Of course, by now I have already received several bounces because > some > authors don't have a valid email address... And I'm sure there are folks like me whose [EMAIL PROTECTED] email goes into a black hole. There's just too much spam in it. I've contact instructions in my modules, but that's about it. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Test::Code
X-Posted to Perlmonks (http://perlmonks.org/index.pl?node_id=483100)
I frequently write code that generates anonymous functions on the fly.
However, I often want to verify that these functions are correct
without executing them. To this end, I've started writing Test::Code.
Here's the start of my test suite (more or less):
BEGIN { use_ok 'Test::Code' or die }
ok defined *::is_code{CODE},
'&is_code should be exported to our namespace';
is_code sub { 1 }, sub { 1 },
'Basic subs should match';
is_code sub { 2 }, sub { 1+1 },
'... even if the exact text is not the same';
is_code
sub { print((3 * 4) + shift) },
sub { print 3 * 4 + shift },
'... and parens that do not affect the meaning should work';
ok defined *::isnt_code{CODE},
'&isnt_code should be exported to our namespace';
# How many people would spot the following bug, eh? It's something
# I know I've fallen victim to ...
isnt_code
sub { print (3 * 4) + shift },
sub { print 3 * 4 + shift },
'... and parens that do affect the meaning should fail';
isnt_code
sub { print for 1 .. 4 },
sub { for (1 .. 4) { print } },
'Subtle lexical issues should cause the match to fail (darn it)';
The last example really bugs me. I'd like for that to work, but it
doesn't. Also, variables with different names will fail, even if the
code is functionally identical. I'm currently using B::Deparse to
handle this, but in the long run, I'd really prefer to be able to use
PPI::Normal and fail back to B::Deparse.
Right now, this test module is not as useful as I would like due to
caveats listed above. Suggestions welcome.
Cheers,
Ovid
--
If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Test::Code
--- Michael G Schwern <[EMAIL PROTECTED]> wrote:
> > ok defined *::is_code{CODE},
> > '&is_code should be exported to our namespace';
>
> I usually do this with can_ok()
>
> can_ok( __PACKAGE__, qw(is_code isnt_code) );
I specifically avoid that with methods because &can_ok provides a
default description which implies a method call. If I'm testing a
function, not a method, the default description is misleading.
> is_code() is a sucky name as it more says to me "is this code" not
> "is X
> routine the same as Y routine". You know this, but I thought I'd
> kick off the discussion here.
Agreed. I think eq_code is better.
Cheers,
Ovid
--
If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Test::Code
--- Ivan Tubert-Brohman <[EMAIL PROTECTED]> wrote:
> Isn't
>
>ok defined *::is_code{CODE};
>
> just a convoluted way of saying
>
>ok defined &is_code;
Er, yes. It is. That's just a really bad habit on my part. I do a
fair amount of typeglob diddling, so that tends to stick in my mind.
Thanks for the reminder.
Cheers,
Ovid
--
If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Test::Code
--- demerphq <[EMAIL PROTECTED]> wrote: > One idea might be to try using Data::Dump::Streamer for your tests. > It > will serialize the lexical context that the subroutine was compiled > with (including bound anonymous subroutines and their lexical > context). > > A small hack (that i would be happy to work with you to put into the > next release) might allow you to rename the vars the in the sub as > you > wanted. IE, it could normalize all vars that are lexical bound to the > subroutine so that comparisons would be easier. Of course by default > DDS wouldnt consider the subs the same unless the values of said vars > were the same too... That's sounds wonderful. The other day I was actually looking into what it might take to hack B::Deparse to normalize the variable names. Then I looked at the code :) (It actually didn't look that hard, but I haven't tried yet). I won't have time to return to this problem for a couple of days, but I'm glad to know there's a path to follow. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
kwalitee: drop Acme?
--- David Golden <[EMAIL PROTECTED]> wrote: > Where it becomes into a competition rather than a developer's tool > is that the scores are added together into one "Kwalitee" score > that assumes (or for which people assume): Frankly, I think it's human nature to compete. Anytime someone puts up something whereby strict criteria can be used to assign a "score" to something (regardless of whether or not we agree with the chosen criteria), folks are going to note how their doing in relation to others. It doesn't matter whether or not people like this. If these scores are going to be public, for some it will be a competition. Myself, I was happy to see CPANTs and I "knew" I put out good quality code, but in retrospect, I do see from the metrics that there are some areas where I can improve. I do wonder, though, why Acme:: files are included in there. The very nature of these modules frequently guarantees that Kwalitee scores will be dragged down. Taking a less than random example: Acme::Code::Police No one is *ever* going to use this as a prereq (if they do, they should be first against the wall when the Acme::Code::FreedomFighter comes). Further, I can't use strict in that module (doing so would kill a bit of irony). And POD coverage for a module that consists of one line of code? We should at least throw the poor module author's a bone and leave Acme:: out of this. Cheers, Ovid PS: Someone should really write Acme::Code::Police::State. It would search for instances of Acme::Code::FreedomFighter and rename it to Acme::Code::Terrorist. Then recreate a new Acme::Code::FreedomFighter and symlink it to Terrorist.pm :) Turning the resulting State.pm into ASCII art of one's favorite hated politician is optional. -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: kwalitee: drop Acme?
--- David Golden <[EMAIL PROTECTED]> wrote: > It can't be by the same author, though, to count for is_prereq, > right? Nope. http://cpants.perl.org/dist/Lingua-EN-NameParse. I think I can create a Bundle::Ovid and win this point. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: kwalitee: drop Acme?
--- Adam Kennedy <[EMAIL PROTECTED]> wrote: > Ditch the CPANTs elements that a fail-by-default. By that I mean > has_test_pod_coverage, is_prereq and possibly also has_test_pod. The is_prereq is the only one that really annoys me. If folks start using module-starter, they'll likely pass the pod tests (unlike me). Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Sub::Uplevel
Hi all, Guess what the following modules all have in common (aside from the fact that I wrote them)? AI::NeuralNet::Simple AI::Prolog Games::Maze::FirstPerson All of them have failed at one time or another because the target computer didn't have Sub::Uplevel installed. I'm going to have to track down what's really causing that, but I'm getting tired enough of that failure being reported and I'm thinking about just making that damned module a requirement in packages, despite the fact that I'm not using it directly. That, however, is a big bucket of suck. How do you handle issues like this or is this one common enough that someone knows the offending party? Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Test::Harness Extension/Replacement with Color Hilighting
--- Tels <[EMAIL PROTECTED]> wrote: > > So I think a spin-off of Test::Harness which will facilitate doing > that > > is still in order. > > Why not fix Test::Harness instead of re-inventing it entirely? That's my thought. It's been known for a long time that Test::Harness works well, but only for the specific task it's been designed for. There's been a lot of discussion about improving/extending it. This is a much better solution than making a fork for a feature that's likely not compelling enough for folks to make the switch. Don't get me wrong. I also want color highlighting of test code. However, there's a lot more stuff I would like to do with the test output (imagine a Wx extension that provides the red/green color bars that JUnit provides). By fixing Test::Harness, we get a more general case solution and everybody wins. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: ENV problems with testing
--- Michael G Schwern <[EMAIL PROTECTED]> wrote:
> > 5.005 introduced qr//
> >
> > $ ~/Reference/5.005_04/bin/perl5.00504-32 -le '$r = qr/(p...)/; $^X
> =~ $r; print $1'
> > perl
>
> If you're using it for any serious amount of nesting (ie. building up
> a regex
> with a bunch of qr's) it didn't really stabilize until 5.6. I recall
> this
> from Email::Find and URI::Find. But for normal use its ok in 5.5.
FYI: Deeply nesting qr// constructs can have performance impacts.
ovid $ perl -le '$x=qr{x};$y = qr{y$x};print qr{$y};'
(?-xism:y(?-xism:x))
Perl will decompile the individual regexes back to strings and later
recompile them. This recompilation can produce less efficient regexes
than what you wrote. A better solution, if this turns out to impact
one's code, is to use the q{} and qq{} operators and nest them, though
when you use qq{} you'll have to remember to properly escape things.
Also, you'll want (?:) constructs in your code.
bin $ perl -le '$x=q{(?:x)};$y = q{(?:y$x)};print qr{$y};'
(?-xism:(?:y$x))
See Perl Best Practices "Constructing Regexes" (page 261) for more
information.
Cheers,
Ovid
--
If this message is a response to a question on a mailing list, please send
follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Test Suite Slowing Down My Development
Hi all, I suspect that most of us who do test-driven development will probably argue that tests do not slow down our development or, better still, will speed up our development. Usually I find this is true for myself, but not now. I could really use feedback on http://perlmonks.org/index.pl?node_id=503758. In short, I need to use a different strategy to get around the problems outlined in that node (reproduced below). Cheers, Ovid -- One of the less appreciated benefits of test suites is how they speed up development. It seems counter-intuitive as you're writing twice the amount of code, but the experience of many programmers has been that test suites lead to better interfaces, less time spent tracking down bugs and, due to easier refactoring, a smaller code base that's easier to work with. I personally find that I'm getting much more work done now that I write solid test suites. Until now. The code is designed well enough that adding new features is quick and easy. Unfortunately, whenever I need to change my code I fire up a Web server and view the results in the browser and then write the tests after I've written the code (this is closely related to When test-driven development just won't do). This is because XML and XHTML are just text. I need to see the output. I've been finding more and more that small changes in my code are making huge changes in the output and trying to continuously update the tests to exactly match the XML, XSLT and XHTML using Test::XML and XML::XPath has led to a serious productivity drop. I'm considering just using Test::WWW::Mechanize to do integration testing through a Web server I run in the tests. This will be much faster and allow me to get my development speed back up. However, I'd be skipping the unit testing of the output. I'll catch the bugs but it will likely take me longer to track them down. -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: Test Suite Slowing Down My Development
--- "Christopher H. Laco" <[EMAIL PROTECTED]> wrote: > I feel your pain. The test suite for Handel has xml/tt output tests > for > its AxKit and Template Toolkit plugins. I've got oodles of template > pages using the components whos output I compare to static .out > files > that contain the expected output. > > Everytime I write a new plugin, or a new tag in the plugin, I waste > tons > of time just writing the tests for them. So far, I've been good about > writing the tests before I write the code, but it takes forever and I > rarely get the tests right the first time. It might be nice if you posted this comment to http://perlmonks.org/index.pl?node_id=503758 If others can see that this is not an unusual problem it might help. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
CPAN Testers results
Hi all, I've noticed that http://search.cpan.org/~ovid/HOP-Parser-0.01/, amongst other modules, has no CPAN test results appearing even though CPAN tester reports are coming in. I've seen this for other modules, too. Is there an announced reason for this I missed or is something down? Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
RFC: Test::JSON
Hi all, For all of my harping about testing, I've never actually written a test module (though I've submitted patches). I just uploaded my first module, Test::JSON. (JSON is "JavaScript Object Notation", http://www.crockford.com/JSON/). As it's not hit the CPAN yet, I've attached a copy. Feedback welcome. Internally it uses the following: 'JSON' => 1.00, 'Test::Differences' => 0.47, 'Test::Simple' => 0.62, 'Test::Tester' => 0.103, Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/ Test-JSON-0.01.tar.gz Description: 130210938-Test-JSON-0.01.tar.gz
