or
whatever.
Clearly, the devil is in the details and this is a really simple example,
but if one is not adverse to playing with some globals, it seems doable.
(Albeit requiring writing a complete alternative to Test::Harness...)
Regards,
David Golden
-
Michael G Schwern wrote:
On Wed, Jan 26, 2005 at 05:55:24PM -0500, David Golden wrote:
While this simple example just has the test function shove a reference to a
hash onto a global array @{$Tester::RESULTS{$filename}}, the test function
could just as easily create an object (Test::Object::Ok
If this discussion means the voting has re-opened, I'm in favor of 'label'
as it implies an identifying description, but also connotes something brief.
David
Stevan Little wrote:
I sent Schwern a patch to change 'names' to 'description', but then Andy
brought up the idea of 'labels'. At the time
ou get the line count.)
You can provide a utility function that returns a string with the output for
people to write custom tests against:
stdout_capture { fcn() };
Regards,
David Golden
James E Keenan wrote:
And here are the fruits of my application of IO::Capture: a module with
three subro
Ofer Nave wrote:
I've written a new module for CPAN called Parallel::Simple. It's my
first CPAN module, and I have not yet uploaded it because I have not
yet written any formal tests for it (although I use it in production
currently). I've also never written any formal tests in perl at all
(u
particular form of output. That would mean that someone could use
Test::Builder::TAP (for TAP style output) or Test::Builder::HTML for
custom output purposes. (As opposed to the current approach of using
Test::Builder to speak TAP to Test::Harness to gather results to either
print or do other things with.)
Regards,
David Golden
Michael G Schwern wrote:
On Tue, Mar 08, 2005 at 03:39:17PM -0500, Michael Graham wrote:
Something that's been sitting in the Test::Builder repository for a while
now is Test::Builder->create. Finally you can create a second Test::Builder
instance. I haven't done much with it and I think $Leve
chromatic wrote:
On Tue, 2005-03-08 at 14:54 -0500, David Golden wrote:
Also, in thinking through the reorg of Test::Builder, it would be great
if the notion of "success" or "failure" could be isolated from any
particular form of output. That would mean that someone coul
Michael G Schwern wrote:
On Tue, Mar 08, 2005 at 02:54:46PM -0500, David Golden wrote:
Could we also consider moving away from singletons that are hard-wired
to Test::Builder? By that I mean make Test::Builder a 'factory' that
gives either a default, plain vanilla Test::Builder obje
chromatic wrote:
On Tue, 2005-03-08 at 17:31 -0500, David Golden wrote:
Yeah, it would be nice if we had a better way to handle this. Perhaps
changing the idiom to:
$Test->ok( $dressed_up, 'How nice do you look?' ) ||
$Test->reason( 'Refusing to wear a t
chromatic wrote:
On the other hand, it doesn't do anything differently with TAP as
currently defined, and I share Schwern's case of howling fantods at
recommending that people look in Test::Builder's test results list. Out
of process interpreting and reporting feels so much nicer.
An addendum o
I was playfully suggesting that behind simply as an abstraction of what
Test::Builder and Test::Harness provide. No way would I inflict that on
an end-user!
David
Ofer Nave wrote:
David Golden wrote:
Just to be playful with concepts:
* Test::Answer -- holds the details of a particular test
Ken Williams wrote:
On Mar 30, 2005, at 6:16 PM, Michael G Schwern wrote:
On Wed, Mar 30, 2005 at 05:53:37PM -0500, Randy W. Sims wrote:
Should we completely open this up so that requires/recommends/conflicts
can be applied to any action?
install_recommends => ...
testcover_requires => ...
etc.
Th
hings to include in a "high quality" test suite.)
David Golden
Christopher H. Laco wrote:
Because they're two seperate issues.
First, checking the pod syntax is ok for the obvious reasons. Broken
pad leads to doc problems.
Second, we're checkling that the AUTHOR is al
it into CPANPLUS as an option along the lines of how test reporting is
done. Make it a user choice, not a mandated action.
Ironically, for all the skeptical comments about "why a scoreboard" --
the fact that many people care about the Kwalitee metric suggests that
it does serve some inspirational purpose.
Regards,
David Golden
e
boolean context, the "$p || $q" idiom is (I think) pretty much logically
equivalent to a trinary operation "$p ? $p : $q" (ignoring potential
side effects) and thus the truth table in this situation only needs to
include the first operand, thus avoiding the false-alarm.
Regards,
David Golden
dule. In such a case, one option could be to use "foo( $p ||
$q || '' )" or, more precisely, "foo( $p || $q || $q )" -- which are
awkward, but are actually forcing the program to evaluate $q as true or
false.
I guess that begs the question for coverage testers which case is more
common -- caring only that "$p || $q" takes on the value of $p and $q,
or caring that both $p and $q take on both true and false values.
Regards,
David Golden
seems to be
the possibility of doing this -- though I freely admit that I don't
understand perlguts well enough to say.
Regards,
David Golden
t::Common;" in that
file, and then "use t::Common" in your tests scripts. (This assume that you
run your tests from the directory above "t/" so that "t::Common" finds your
module.)
Regards,
David Golden
s my
inline pod. If you want to fold both, don't make the edit to perl.vim and
set "let perl_fold=1") When I want to edit a folded pod section, "zo" opens
a fold and "zc" closes it. "zn" opens them all and "zN" closes them all.
Makes inline pod less frustrating, particularly if you write lengthy docs.
Regards,
David Golden
Ivan Tubert-Brohman wrote:
Isn't
ok defined *::is_code{CODE};
just a convoluted way of saying
ok defined &is_code;
Won't "&is_code" get called that way? Should this be:
ok defined \&is_code;
David Golden
if Module::Build added a "noindex" option directly. Maybe
after the 0.27 release.
Regards,
David Golden
the tests and invest processor
cycles on it, more power to them.
Regards,
David Golden
his a lot. I'd drop "has_perl_dependency" and just have
"bad_perl_dependency" fail if there is no perl dependency listed. I.e.,
assume that no perl dependency is equivalent to "use perl 0" or maybe some
arbitrarily old version of perl 5 (e.g. 5.004).
Regards,
David Golden
or a "core Kwalitee" or
whatever subset they think matters. Some of that might be useful for
installers, and some not. But if CPANTS itself didn't offer a Kwalitee
score -- just the results of the tests -- there wouldn't be an implicit
sanction of a single metric that gets people so riled up.
Regards,
David Golden
It can't be by the same author, though, to count for is_prereq, right?
So someone needs to create a new CPAN ID, and release a module under that ID
that prereqs all of CPAN. Then we'd all get our prereq points.
Probably could be done with a Build.PL that pulls the full module list then
const
Ovid wrote:
--- 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.
Yup. (I think.) Listed as a prereq by Lingua-EN-MatchNames by BRIANL.
http://cpants.pe
Adam Kennedy 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.
Or make is_prereq SO easy to game that it's a nonissue? Why should a
module depended upon by another author be ranked any higher than one
that
At least one of the culprits may be Test::Exception, for any version before
0.20. The problem is that CPANPLUS doesn't currently play well with
Module::Build and doesn't respect the "build_requires" parameter, but only
looks at the "requires" parameter. So you'll get unexpected failures for
t
you were proposing a kwalitee test to see if there was more than one release
of a distribution, or more than one release in the last X amount of time.
Maybe that will become a "has_changed" metric someday -- a rolling stone
gathers no moss. I'm kidding, of course.)
David Golden
and pod coverage tests, a Changes file with "See
DBI::Changes" or "See Readme" would satisfy the kwalitee test. It a hack to
satisfy the metric, but has the side benefit of actually providing a
consistent place for someone to track down the actual location of the change
log.
Regards,
David Golden
polite question is wonderful (with potential answers ranging from
"sure" to "hey, that's a cool idea, let's try a merge instead of a fork").
After the recent CPANPLUS::Dist::Build debacle, a little politeness in the
community is nice to see.
David Golden
David Landgren wrote:
Yeah, but I'm loathe to dedicate two separate test files merely to score
two points of Kwalitee. As it is, I'd just much rather bundle both tests
in a 00_basic.t file along with all the other standard no-brainer tests.
One option is just to forget about the two points of
Test::Harness count as a "module of consequence"?
- David Golden
Adam Kennedy wrote:
What about a special environment variable, like RUN_PRIVATE_TESTS?
I've been working on a concept of taggable tests on some of my larger
commercial stuff, integrating with the Test::More skip() function, and
some form of environment variables does indeed seem the best way
Before I flounder around to figure this out, I hope that a quick message to
the list can offer some guidance.
I've got a bunch of test files for a distribution that run a script that
comes with the distribution. I'd like to test my coverage against that
script. I figure that I can just pass
Paul Johnson wrote:
On Wed, Nov 16, 2005 at 05:46:34PM -0500, David Golden wrote:
I've got a bunch of test files for a distribution that run a script that
comes with the distribution. I'd like to test my coverage against that
script. I figure that I can just pass "-MDevel
lti
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.5
/usr/lib/perl5/vendor_perl/5.8.4
/usr/lib/perl5/vendor_perl/5.8.3
/usr/lib/perl5/vendor_perl/5.8.2
/usr/lib/perl5/vendor_perl/5.8.1
/usr/lib/perl5/vendor_perl/5.8.0
/usr/lib/perl5/vendor_perl
.
Insights and suggestions are greatly appreciated.
Regards,
David Golden
James E Keenan wrote:
What happens with: prove -vb t/sort_bug.t
It was in the next section via make with TEST_VERBOSE. Subtests
complete successfully then the test dies.
t/sort_bug1..2
# parent 2267: continue
# kid 1 before eq_set
# parent 2267: continue
# parent 2267: waiting for joi
and how do you load them? Is there
a naming convention that most people follow (e.g.
t::Foo::Bar).
I've personally come to like the "t::Foo::Bar" style as it is
immediately obvious that the module in question is test-related. It's a
handy affordance.
Regards,
David Golden
Adam Kennedy wrote:
Likewise, if your module installs all the way from a vanilla
installation and all it dependencies go on cleanly, then I think that's
well and truly worthy of a point.
Something like a clean_install metric. If there are any FAIL entries in
CPAN Testers against the current v
Adam Kennedy wrote:
Whether or not that is a transient thing that lasts for a week, or a
serious and ongoing problem, I think it's still worth it.
But that would require regular scanning -- otherwise I might get the
point one week and then a dependency might upgrade in a way that is
borked.
Chris Dolan wrote:
writing fragile META.yml creation code. YAML.pm is not even at 1.00
yet, so an API change is allowed by convention, and lack of
Convention? On CPAN? Are you kidding? By that logic, many of the
commonly used tools on CPAN could change API and your answer would be
"oh,
Adam Kennedy wrote:
And therein lies the problem.
Working out when a dependency is important and when it's useless, or
vanity, or lazyness (good or bad) or whatever requires a human judgment
call.
So we can't really do anything about it.
Is it OK to use a lot of dependencies if they all wor
demerphq wrote:
On 1/30/06, David Cantrell <[EMAIL PROTECTED]> wrote:
Adam Kennedy wrote:
A testing system should only be sending FAIL reports when it believes it
has a platform that is compatible with the needs of the module, but when
it tries to install tests fail.
So how, then, do I tell
David Cantrell wrote:
David Golden wrote:
What's a clean, generic mechanism for a distribution to signal "please
check this dependency and abort if it's not satisfied"?
die("wrong platform, you didn't read the documentation\n")
unless(
$Config::cap
over a week ago about
the build system using an outdated version of Scalar::Util that doesn't
have "refaddr". (Which is surprising, since they offer an updated one in
their repository.) To date, I haven't even received a ticket response
acknowledging receipt of my message, m
itive.
If you would like to see examples of how I have used it, look at the
test files for ExtUtils::ModuleMaker::TT -- particularly
t/20_makeperlmod.t and t/CLI.pm.
Best of luck,
David Golden
on the module's CPAN Testers results page.
Again, I don't think overwriting is a good idea. What if some
dependency module was changed and caused the module to fail/succeed
differently than before? That's important to know. Different results
from the same tester is *valuable* da
A. Pagaltzis wrote:
* David Golden <[EMAIL PROTECTED]> [2006-03-13 23:05]:
This issue also has frustrated me for some time, but I don't
think that we should be considering deleting reports. Reports
are just facts -- they have no value basis. Yes, people may make
judgments about the
he test label in the
case as well.
Test::Base makes that all a bit more automatic, but I prefer to avoid it
so that simple little modules I write don't suddenly inherit a big
build_requires dependency chain.
Regards,
David Golden
Adam Kennedy wrote:
For all those component distributions I consider it a failure if it is
so complex that you need something more than just three or four lines
from the SYNOPSIS.
Maybe there should be a Kwalitee metric for the length of the synopsis?
:-)
Regards,
David Golden
Does anyone have an inside
contact at ActiveState that can shed some more light on the subject?
Regards,
David Golden
m this URL: 1.15 seems to build OK on windows:
http://ppm.activestate.com/BuildStatus/5.8-windows/windows-5.8/Scalar-List-Util-1.15.txt
Even on linux, the PPM build system seems to be using an older version:
http://ppm.activestate.com/BuildStatus/5.8-linux/linux-5.8/Class-InsideOut-0.11.txt
Rega
listic approach might be to have the 8xx repository as
is (always building against the first release at that major) and just
*one* 8NX repository that always builds against the *latest* release
(whatever that is at any point in time).
Regards,
David Golden
ted approaches requiring
changes in the Windows registry in order to finish upgrades during a reboot.
Thoughts and feedback welcome.
Regards,
David Golden
l problems after
that, we take the next step.
That's good news. I hope the Schwern bottleneck clearly up soon.
Regards,
David Golden
demerphq wrote:
The point i was making is that it isnt actually necessary for Schwern
to do anything for you to enjoy the benefits of the new Install code.
> [snip]
cpan> install YVES/ex-ExtUtils-Install-1.3701.tar.gz
the you are cooking, with gas, right now. :-)
That's great, but I want e
where behavior has
fewer degrees of freedom. Then the benefits in terms of positive
reinforcement of task completion and the safety net against future
breakage still apply.
David Golden
ctually part of passing a test. (Generally, conditional
branches not taken are what show up here.)
Regards,
David Golden
Randy W. Sims wrote:
Yep, that's ridiculous. I used to see these questions a lot back when I
was answering mails on the beginner groups. People wanting to do things
that have already been done and widely tested, but everyone wants to
write their own in order to "reduce dependencies".
Reinvent
also wrote Exception::Class::TryCatch for a
little more helpful sugar:
eval {
# do stuff;
};
# catch() upgrades non-object $@ to Exception::Class::Base
if ( catch my $err ) {
if ( $err->isa('My::Exception') ) {
# handle it
}
else {
$err->rethrow;
}
}
Regards,
David Golden
James E Keenan wrote:
Let's say that I'm writing a test suite for a Perl module which creates
files and then, optionally, moves those files to predetermined
directories. To test this module's functionality, I would have to see
what happens when the user running the tests does not have write
p
scores -- then it doesn't.
If CPANTS stays with a narrow set of well-defined, objective criteria,
then it can serve both purposes. Remove or refine the subjective or
hard-to-measure ones and the numerical gaming that doesn't change
apparent quality goes away.
Regards,
David Golden
Chris Dolan wrote:
is_prereq is usually a proxy metric for software maturity: if someone
thinks your module is good enough that he would rather depend on it than
reinvent it, then it's probably a better-than-average module on CPAN.
is_prereq is usually a vote of confidence, so it is likely a g
got plenty of test fixtures where subroutine X with tests calls
subroutine Y with tests. Or a loop calls a subroutine with tests. It
would be intuitive to group and nest those.
David Golden
t is already minimal.
Regards,
David Golden
Regardless, I encourage PAUSE admins to better document how CPAN uses
no_index (as it currently points to a missing spec file, no less).
Thank you all very much,
Regards,
David Golden
Randy W. Sims wrote:
I don't know much about SocialText. Is there a converter, so that if you
put something up temporarily in MediaWiki, it can later be converted and
moved to SocialText?
I know there are a whole series of HTML::WikiConverter dialects on CPAN.
I haven't used it, but it seems
Andreas J. Koenig wrote:
The page is there, http://thepierianspring.org/perl/meta/, but does
not provide direct statistics so I made up my own.
no_index/dir 13
no_index/directory 1397
private/directory40
David's D/DA/DAGOLDEN/Perl-Dist-Vanilla-5 used both dir and directo
an integral
distribution like Scalar-List-Utils is using Module::Install 0.37. You
can find a complete (and somewhat current) list of problematic modules
at http://steffen-mueller.net/mi_old.html
Ideas?
What about adding NO_BROKEN_INSTALLER as a Kwalitee point for CPANTS?
:-)
Regards,
Da
bably neither does AS's config hacking.
David Golden
In the last day or so, every time I go to rt.cpan.org, it seems to
nearly finish loading a page and then just stalls.
Deleting the cookie for it seemed to help briefly, and then it stalled
again after submitting a bug report.
Are others experiencing difficulty?
Regards,
David Golden
e the formative project at his public repository:
http://tinyurl.com/g888h
Perhaps you can join forces with him and help push some collective
project towards a release.
Regards,
David Golden
chromatic wrote:
Why is there not a Bundle::PerlPlus (and yes, I've lathered up my yak with
that name) that downloads and installs the modules that should have been in
the box?
For one, that should be "Task::PerlPlus". :-)
Second, for any pre-packaged distribution like Strawberry Perl (see
Thomas Klausner wrote:
I think it's a good metric, but maybe Module::Install-supports will
disagree :-)
Well, as long as it only picks up *certain* versions, that's probably OK.
We could also add checks for problems in Makefile.PL/Build.PL...
At the risk of going out on a limb here, maybe s
e able to be upgraded more frequently than core Perl as issues are
discovered. Many of the issues that module users have are that all they
have is some old version of core Perl with out-of-date CPAN.pm and
EU::MM that are buggy. And they're stuck. That's what M::I is trying
to solve.
Regards,
David Golden
fun and profit
* Laugh at code that gets its slashes wrong
(*cough* Test::Pod *cough*)
(*cough* Template Toolkit*cough*)
Regards,
David Golden
Andy Lester wrote:
On Jul 19, 2006, at 4:13 AM, David Golden wrote:
* Laugh at code that gets its slashes wrong
(*cough* Test::Pod *cough*)
I thought I'd fixed your slashie problems long ago. No? Please lean on
me if not.
http://rt.cpan.org/Public/Bug/Display.html?id=
demerphq wrote:
On 7/19/06, David Golden <[EMAIL PROTECTED]> wrote:
* Laugh at code that gets its slashes wrong
Thats a strange one, how often is this really a problem on win32? I
cant think of many times when thats been a problem.
It's not so much the frequency as the f
an? Or put differently,
if we tracked the percent of CPAN modules that got the quality point for
each of the metrics, how would that graph trend over time? More "use
strict"? More "META.yml"? More "README"?
Regards,
David Golden
backwards compatibility. I think that the
version object should be stringified when added to META.yml.
Regards,
David Golden
John Peacock wrote:
David Golden wrote:
[cc'd to perl-qa for awareness of the issue]
The switch to version objects in Module::Build means that the generated
META.yml now has this:
Is this with or without YAML itself loaded (so I know where to start)?
I did a little digging and this
Steffen Mueller wrote:
John Peacock schrieb:
David Golden wrote:
(Though technically, it really ought to check that the ref equals
"Module::Build::Version").
No, that would be wrong too. Never test a ref() against a specific
object
class, since it paints you into a corner with i
_id=349737
Regards,
David Golden
e of my favorite handy, hacky things -- easy block comments:
",ic" insert comment mark
",rc" remove comment mark
vmap ,ic :s/^/#/g:let @/ = ""
vmap ,rc :s/^#//g:let @/ = ""
map ,ic :s/^/#/g:let @/ = ""
map ,rc :s/^#//g:let @/ = ""
Regards,
David Golden
s the
option of automatically generating and emailing test reports whenever
tests are run via CPAN.pm.
Any other feedback or suggestions are greatly appreciated.
Regards,
David Golden
Ovid wrote:
> tests finished
I like it. Backward compatible and elegant in its declarative style.
(Therefor probably too good to be true.)
Regards,
David Golden
Ovid wrote:
Are there any Test:: modules which test the STDERR output directly or something
like that?
* Test::Output
* IO::Capture
There are tests that specifically check what's being sent to STDERR (as
well as STDOUT). Of course, these modules intercept STDOUT and STDERR
to keep them awa
vel::Cover to collect coverage
information from these tests as well?
They probably need to be run in the same process. What about using
Test::Output or IO::Capture to capture the output (and keep it from
Test::Harness) and just running the code with "do code.pl"?
Regards,
David Golden
n inc/
I'm not convinced that you can get this idea to work short of caching
the full distribution directory or tarball at install-time and then
iterating through those using the actual Makefile.PL or Build.PL files
to prep and call tests.
Regards,
David Golden
Adam Kennedy wrote:
But with that in mind, I still don't see much point in running them at
install-time, so lately I've modified my pod.t test so that it's skip
message is now "skipped: Author tests not required for installation" or
the like, and the tests now only run when AUTOMATED_TESTING is
Thomas Klausner wrote:
Maybe it would be reasonable to also check for a POD-Heading named
LICENSE, but that's definitly more error-prone.
If you're going that way, also check for a qr/LICENSE/i file in the
distribution directory.
Maybe this metric should even check if there's a license in M
brian d foy wrote:
Thinking about this further and talking to a few people about it, the
only place that makes any sense is the source code file itself. After
installation, the rest of the distribution will disappear. The license
has to stay with the source.
Nit -- .pod files also stay around a
houldn't* work and unexpected success is
really wrong, then it should be written as a normal test of the failure
case.
TODO means "don't have the result of this test affect the outcome yet".
Regards,
David Golden
forks and process control
* assumptions of unix command tool availability
* signal handling
I think authors need to aim to have the quality of test code be the same
as the quality of module code. (Though I'll admit that I don't always
live up to that standard myself.)
Regards,
David Golden
recipe in perldoc seems to
imply you could reopen STDERR to a duplicate of STDOUT (after
redirecting it) to capture both to the same place.
As a side note, it would be nice if IO::Capture or Test::Output used
that method instead of ties so they could be used with external
processes, too.
In the meantime, I'd suggest trying it with IPC::Run3, which should do
the right thing.
Regards,
David Golden
David Cantrell wrote:
clearly. So my attempt to make my tests good will mostly consist of
applying the same coding standards to the test suites as I do to the
rest of the code.
OK, Lazy Web, who's going to write Test::Test::Perl::Critic?
:-)
Any tips on what - other than comprehensiveness,
I assume the idea behind not taking things off is to keep the history
available for future reference. Even if someone deletes an old
tarball of CPAN, I want to see the test history for it. I look not
only at current versions, but at past versions for judging robustness.
If a modules is renamed
'd
really like to have in a test report. Which would you prioritize?
Regards,
David Golden
1 - 100 of 402 matches
Mail list logo
