Hello,
Is there any way to tell if my package is being tested automatically
under CPAN::Testers? Here's the situation:
I have a DBI extension (DBIx::Transaction) whose unit tests
currently depend on a valid DSN being available. SQLite makes a good testbed
for mock databases, so
Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote:
For CPAN smokers based on CPAN::YACSmoke, the answer is: test the
presence of the AUTOMATED_TESTING environment variable. See also
the following page for more details:
http://search.cpan.org/dist/CPAN-YACSmoke/lib/CPAN/YACSmoke/FAQ.pod
Jeffrey Thalhammer [EMAIL PROTECTED] wrote:
* Should a test script have a shebang? What should it
be? Any flags on that?
It's not at all neccessary, but IMHO it is good form; it's a surefire way
for anything else (HTTP server, IDEs, etc) to figure out that you're
actually a perl script and do
On several of my modules, the search.cpan.org page shows test
passes/failures, whereas when I follow the link to see the actual list,
there are no tests reported.
eg: http://search.cpan.org/~CRAKRJACK/Class-Driver-0.004/
Usually this clears up in about a day, but in some cases it's been
Chris Dolan [EMAIL PROTECTED] wrote:
* for windows only
* only includes Foo-Bar, but not it's dependecies
It will auto-install dependencies just like CPAN, I believe. And,
yes, it's currently Windows-only. Didn't you offer bonus points for
Windows??
Um, no it isn't!
Jeffrey Thalhammer [EMAIL PROTECTED] wrote:
Randy Kobes distributes Win32 PPMs for some of the
modules that ActiveState doesn't provide. It is not
entirely automated, so the latest code isn't always
available. But Randy is very helpful if there's
anything you want to see.
Gabor Szabo [EMAIL PROTECTED] wrote:
I have just moved to Ubuntu and thought I will try to rely on apt-get
to install my Perl modules. Quckly I hit a wall and could not install some
of the basic modules. I did not have the time to investigate and check
if I made a mistake or if there is a .deb
Barbie [EMAIL PROTECTED] wrote:
I'm one of the maintainers/developers for CPAN::YACSmoke. I was
intrigued by your post about adding a Packager plugin to it. However,
I'm unclear as to what purpose it would serve. CPAN::YACSmoke is purely
about reporting on test results. CPANPLUS does the
Gabor Szabo [EMAIL PROTECTED] wrote:
You simple cannot guess what libraries/compiler/system/kernel the user
has installed, unless you know the distribution and version *and* require
that the user never updates anything.
I think I agree. That's what I would like to see solved. If I stick
Andreas J. Koenig [EMAIL PROTECTED] wrote:
FWIW, we're using dh-make-perl to create debian packages from CPAN
modules.
Andreas,
I've used this tool a few times when a CPAN module wasn't already
available in unstable/main, but I havent looked into it too closely. I'm
curious, does it do
Leon Brocard [EMAIL PROTECTED] wrote:
Usually this clears up in about a day, but in some cases it's been 3 or 4
days now and search.cpan.org is telling me that tests have run, but
testers.cpan.org doesn't seem to know anything about them.
Sorry, I'll prod testers.cpan.org again. Give it a
Take a look at this output:
http://www.nntp.perl.org/group/perl.cpan.testers/285112
It looks like this particular system is not noticing that Test::Exception
requires Sub::Uplevel, then gets confused thinking it was *my* module that
needed Sub::Uplevel. What's even more concerning is the
Fergal Daly [EMAIL PROTECTED] wrote:
I have a fail against a module for exactly the same reason. I
initially blamed Module::Build but they convinced me it was Imacat's
setup. Apparently the output looks like an old version of something or
other.
http://rt.cpan.org/NoAuth/Bug.html?id=15034
OK, speaking of Kwalitee, I saw cpants for the first time today.
And saw that it claims to update every sunday, but there hasn't been an
update since december 5th. I also saw this interesting .pm file that
appeared to have an anonymous hash of every tarball in CPAN in it, all on
one line.
imacat [EMAIL PROTECTED] wrote:
That sucks. :-( If imacat's box has gone AWOL, is there anything
cpan testers can do to flag it as such? At least until his/her attention is
grabbed and the problem is addressed?
I'll look into it and return ASAP. It's Chinese New Year here, so
Greg Matheson [EMAIL PROTECTED] wrote:
On Tue, 31 Jan 2006, Tyler MacDonald wrote:
Take a look at this output:
http://www.nntp.perl.org/group/perl.cpan.testers/285112
It looks like this particular system is not noticing that Test::Exception
requires Sub::Uplevel, then gets confused
Chris Dolan [EMAIL PROTECTED] wrote:
There is a class of tests that module authors perform that end users
are not expected to run. For example code coverage tests, spelling
tests, coding style tests, etc. These tests are either prohibitively
expensive or complicated or unpredictable
Adam Kennedy [EMAIL PROTECTED] wrote:
Write this up. Then exhaustively test it on every single Perl platform
(50ish?) and every Perl version back to 5.004, including a random
collection similarly weird combinations (5.004 VMS, that 5.6.0 from
RedHat 7, 5.6.1 on Windows 95).
I let
Steffen Mueller [EMAIL PROTECTED] wrote:
And now that I think about it, I'm not so convinced about that whole
concenience for the end user nonsense. If they're mucking about
installing perl modules from the CPAN packages by themself, they're
probably developers that need some extra time
Chris Dolan [EMAIL PROTECTED] wrote:
* copyright.t - Ensures that there is a Copyright .([localtime]-
[5]+1900) somewhere in every .pm file. Will break 11 months from now.
* distribution.t - Relies on Test::Distribution, which is not in my
prereq list
* perlcritic.t - Runs
A. Pagaltzis [EMAIL PROTECTED] wrote:
I was just gonna say. It???s pointless for anyone but the author to
check POD or test coverage.
I agree about the POD coverage. But if I got a different level of
code coverage on somebody else's system than my own? I'd be very interested
in finding
Offer Kaye [EMAIL PROTECTED] wrote:
Why not start off by providing ppm.cpan.org (as the OP suggested for
linux distors), or something similar? There are many modules that I
want to use where the PPM version provided by ActiveState or some
other repository is badly of out date..
Offer Kaye [EMAIL PROTECTED] wrote:
Just an example, IO::All [1] version 0.33 has been available since Dec
17, 2004. It passed testing many times, at least according to its
testers page [2]. My default 5.8.7 ActivePerl distribution lists
IO::All version 0.17 .
According to
Offer Kaye [EMAIL PROTECTED] wrote:
Phillipe Chaisson aka Gozer (one of the mod_perl authors) is
responsible for the ActiveState PPM repositories now,
Hi Gozer, nice to meet you. Gratz on ActiveState's move to a new
company, good luck :)
It's a Good Thing for all companies
Tamas Dober [EMAIL PROTECTED] wrote:
Hello,
I'm a beginner, please forgive me b/c of the simple questions.
I'd like to test that that a batch file (starting a Java app) gives me the
expected output or not.
I really like IPC::Run, but it is a bit of a heavy package to make
users
Adam,
I have one more edgey case I'd like to see on this list:
13. Tests exist, but fail to be executed.
There is tests, but the tests themselves aren't failing.
It's the build-process that is failing.
14. Tests run, and some/all tests fail.
The normal FAIL case due
Adam Kennedy [EMAIL PROTECTED] wrote:
Firstly is that it might turn an otherwise normal result into something
else, with no clear rule. It makes a judgement call that some level of
testing is good or bad, which isn't really the place of an installer to
call.
The reason Kwalitee has
Adam Kennedy [EMAIL PROTECTED] wrote:
I'd still like such a thing to be visible in some way. Of course
you're going to happily skip tests that require a database if you don't
have DBI_DSN set.
Not necesarily... it all depends on how important it is to you. I see
some potential cases
I've been thinking about automated testing again. I know this is a
bad habit and I should stop it and just get on with my work, but here's
where I'm at:
Sometimes it's beneficial for an automated tester to install
additional packages (in software I'm releasing, Test::CPANpm and
Adam Kennedy [EMAIL PROTECTED] wrote:
So while we are on the subject of META.yml, I think the dynamic_config
approach is horrible, because it defaults to an efficient error case and
relies on the author to fix the error, rather than defaulting to the
inefficient correct case, and giving the
Hello Matisse,
I like these two ideas:
Matisse Enzer [EMAIL PROTECTED] wrote:
2) Put the CPAN .tar.gz files in a local CPAN repository and use
CPAN::Site to install - that way we *only* get the versions in
our local CPAN repository and dependencies are managed by the
Matisse Enzer [EMAIL PROTECTED] wrote:
Jeff I think that is a good theory - I mean, it is a testable theory.
I hope it is true, but I am not sure. I suggest you interview a few
IT managers - come up with a list of 6 questions and ask them to
answer in email - I can introduce you to a
Steve Peters [EMAIL PROTECTED] wrote:
/eg scripts are a nice hands-on way of finding out how a module works
in real life.
No distribution should be without one!
Unless, of course, it has an examples/ directory, which would cause the
kwalitee test to fail. ;) I do think its a good
David Golden [EMAIL PROTECTED] wrote:
So back at the beginning of February, there was some email traffic about
how ActiveState's automated PPM build system was using an outdated
version of Scalar-List-Utils, which was causing a cascading prerequisite
failure for many distributions.
Has
Geoffrey Young [EMAIL PROTECTED] wrote:
I was suggesting the functionality be added to Test::More as compile_ok(),
rather than runperl() in some separate CPAN module, as it seems to closely
parallel use_ok() for modules and would be rather useful on a larger scale.
I agree, a well
I just got some cpan testers reports on a new module, CGI::JSONRPC. 1 pass,
2 failures. One of the failures seems to be my fault, but the other one
seems really odd:
http://www.nntp.perl.org/group/perl.cpan.testers/298838
The odd part is here:
[ERROR] [Wed Mar 15 10:06:14 2006] MAKE TEST
Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote:
OTOH, who still runs pre-5.8.x code deserves what they get.
There are horrible bugs in older Perls, and I don't know why people
still
insist using insecure, buggy and feature-lacking code like 5.6. or even
gasp 5.004. Just think Unicode
Ovid [EMAIL PROTECTED] wrote:
Tracking the results in an object is a better choice than scraping from
a print buffer. One of the frustrating issues with Perl's testing
tools is the limited flexibility we have due to reading the output from
STDOUT.
I like that aspect about TAP... it's
Michael G Schwern [EMAIL PROTECTED] wrote:
These TAP extension proposals and designs for parsers and questions
for details about the TAP grammar... they should all go into the Wiki.
But the Perl QA Wiki sucks. Its slow. Its spammed. UseModWiki
sucks. And I don't have the time to maintain
Michael G Schwern [EMAIL PROTECTED] wrote:
On 7/5/06, Tyler MacDonald [EMAIL PROTECTED] wrote:
I'd be happy to. yi.org is already running a few mediawikis, as well as
cpants.perl.org. Let me know and I'll get it set up.
You win! Set it up. Let us know when its online. We'll worry about
Michael G Schwern [EMAIL PROTECTED] wrote:
You win! Set it up. Let us know when its online. We'll worry about
getting a proper domain/uri for it later.
Done! http://qa.yi.org/
Thanks!
Could you switch that to perl-qa.yi.org? Just to make it clear this
isn't yi.org's QA
Michael G Schwern [EMAIL PROTECTED] wrote:
Thanks to Tyler MacDonald and yi.org we now have a brand spanking new
wiki! http://perl-qa.yi.org/ is its location, we'll worry about
getting more official domains later.
Since I set up my own server for (then nx, now yi).org 8 years ago
Michael Peters [EMAIL PROTECTED] wrote:
use Test::More tests = 'defer';
and then
plan past_tests = $n;
What benefit would that give? plan() is nice because it provides protection
against you test script exiting prematurely.
stating the obvious
The exact same benefit as
Michael Peters [EMAIL PROTECTED] wrote:
If the calculated result used in the
'plan' at the end does not match the number of tests actually run, then you
know you've got a problem with your test code.
/stating the obvious
So this gives you protection against not being able to count?
Ok, perl-qa.yi.org redirects there now and it looks like everything's
working...
Michael G Schwern [EMAIL PROTECTED] wrote:
Andy Lester wrote:
On Aug 1, 2007, at 5:09 PM, Michael G Schwern wrote:
http://qa.perl.org/ [2] links to:
Ask can fix that. Ask?
Oh wait, qa.perl.org
45 matches
Mail list logo
