IvorW wrote:
-----Original Message-----
From: m.nooning [mailto:[EMAIL PROTECTED]
Sent: 27 February 2006 13:10
To: Steffen Mueller
Cc: par@perl.org
Subject: Re: LWP::User agent vs PAR
Steffen Mueller wrote:
Glenn Linderman wrote:
Hmm. I can't either, this morning. If it recurs, I'll
try to make my
own test case.
Good idea. And don't forget to send me a copy, so it can maybe be
integrated into the PAR core. :)
Thankfully, we have Malcolm's automatted test script, but
I'd like to
increase the number of tests in the future to increase my
confidence in
the code's correctness.
Steffen
If you describe a test in detail, I can help to add it to the
tests. Keep in mind that the tests must work for the least common
denominator developer. For example, a test involving LWP::UserAgent
would fail in an automated test for the average developer, since the
average developer does not have it installed.
That's a case for skipping the test if LWP::UA is not installed:
use Test::More;
BEGIN {
eval "use LWP::UserAgent";
if ($@) {
plan skip_all => "LWP::UserAgent not available";
}
else {
plan tests => # insert number of tests here
}
}
# your tests go here
Point taken. However, one idea that exists is that, if tests involve
non-standard modules, and a new version of said module fails, it could
be be because of PAR, or because of a bug in the said module itself. Or
because of an incomplete or problematic installation of said module. Or
of the user's machine itself that perhaps interferes with the
installation of said module, or .... ?.
If there were only one module test cased, such as LWP, that would not be
a problem. It may be decided that such a test should be included simply
because it is a popular module, assuming that it is. However, there are
quite a few modules that users may want tested. Would we need to
discuss some sort of criteria by which we would say "No" to some and
"Yes" to others. Hmmm. Unless we said "Yes" to them all, and the users
were willing to provide their own test cases, which I would be happy to
put in, if they were hesitant to do it themselves. I now shrug, knowing
that CPAN is pretty big.
If a module is included as part of the tests, eventually we will indeed
get involved in the debugging of that module, or of the user's
installation of it, etcetera. As the number of non-standard modules get
used in the testing of PAR, we may find that a door has been opened that
we woefully regret.
Normally, tests involve the flexing of code that resides internal to the
PAR code itself. I believe we should always be open to adding any
tests that flex as yet untested PAR code. If there is an area of PAR
code that LWP::::UserAgent flexes that is not yet flexed, perhaps we can
discuss how to flex the said PAR code without using any non-standard
module. I think that would be a good direction to go in.
Comments?
