a couple of modules where a lot
of skips are the norm.
Michael
[1] http://search.cpan.org/dist/Config-Context/
http://search.cpan.org/dist/CGI-Application-Plugin-Config-Context/
http://search.cpan.org/dist/CGI-Application-Plugin-AnyTemplate/
[2] HTML::Template is required because it's
to
a module you're testing. Once your modules and your test script are
relatively stable, you can comment out these lines.
Michael
---
Michael Graham <[EMAIL PROTECTED]>
be used to remove test data before the next text runs.
That's another caveat with the PersistentPerl approach - END blocks seem
only to run on the first request.
Michael
---
Michael Graham <[EMAIL PROTECTED]>
STDOUT or STDERR will probably
have problems.
* The usual persistent environment caveats apply: be careful with
redefined subs, global vars; 'require'd code only gets loaded on the
first request, etc.
* Test scripts have to end in a true value.
If there's interest, I'll try to package all this up into a CPAN module.
Michael
---
Michael Graham <[EMAIL PROTECTED]>
these
modules require URI, not Test::URI. In fact, I haven't yet found one
that requires Test::URI.
Michael
---
Michael Graham <[EMAIL PROTECTED]>
pod.t, pod-coverage.t,
00.load.t or any other stock test boilerplate. If there's something left
over, then the module probably has an actual test suite.
Michael
---
Michael Graham <[EMAIL PROTECTED]>
.pm
$ touch t/prereq_lib/Digest/SHA1.pm
$ prove -Ilib -It/prereq_lib t/
Michael
--
Michael Graham <[EMAIL PROTECTED]>
that would be fine too.
I think there's a big difference in kwalitee between a module that has
only the default tests and a module with a hand-crafted test suite. One
of the first things I do when checking out a new module is to check if
there are more than three files in the t/ directory.
Michael
---
Michael Graham <[EMAIL PROTECTED]>
bt that most modules list their optional dependencies, but that's
probably not a big deal. If someone uses my module but doesn't list it
in recommends, and I want my prereq point, then I'll bug them to add it.
Michael
---
Michael Graham <[EMAIL PROTECTED]>
er own modules.
Each auther could have a special empty 'dependent' module for this
purpose. Something like ACME::Prereq::[AUTHOR_ID].
Michael
---
Michael Graham <[EMAIL PROTECTED]>
all get our
'is_prereq' point.
Don't make us release this foolishness outside of ACME::!
Michael
---
Michael Graham <[EMAIL PROTECTED]>
> Michael Graham wrote:
> > Another good reason to ship all of your development tests with code is
> > that it makes it easer for users to submit patches with tests. Or to
> > fork your code and retain all your development tools and methods.
>
> Perl::MinimumVersi
ons can be directed to [EMAIL PROTECTED]
Michael
-------
Michael Graham <[EMAIL PROTECTED]>
YAPC::NA 2005 Toronto - http://www.yapc.org/America/ - [EMAIL PROTECTED]
---
#x27;s docs are considered 'kwalitudinous' on my system.
Maybe I don't know enough about testing and module development to know
that the module still works fine in spite of the failed POD test.
Michael
-----------
Mi
eone else's pod-coverage.t.
Maybe there should be a different way of marking additional private
methods?
Michael
--
Michael Graham <[EMAIL PROTECTED]>
) {
warn "Cannot fork: $!\n";
return;
}
elsif ($pid) {
my $ret = waitpid($pid, 0);
return $ret;
}
do $script or die "Compile errors: $script: [EMAIL PROTECTED]";
exit;
}
Michael
--
Michael Graham <[EMAIL PROTECTED]>
ort but it was something
I was going to play with for a couple of hours.
Michael
--
Michael Graham <[EMAIL PROTECTED]>
gured folks would want to play with it
> particuarly the Test::Builder::Tester guys.
Would this make it possible to run many test scripts (each with its own
plan) within the same perl process? 'Cos that would be nifty.
Michael
--
Michael Graham <[EMAIL PROTECTED]>
elf.
With an -M feature, I could use:
$ cat runtests
#!/bin/sh
prove -I/path/to/modules -MTestConfig $*
Which is (very) slightly cleaner.
Michael
--
Michael Graham <[EMAIL PROTECTED]>
19 matches
Mail list logo
