The PITA / TestBuilder2 BOF at YAPC whacked up this TAP extension.
Test groups in TAP. There are several use-cases here.
1. I want to name a group of tests rather than the individuals.
2. I don't want to have to count up the total number of tests in my
file but I do want the protection of the
On 7/3/06, Ovid [EMAIL PROTECTED] wrote:
Currently, the way that Test::Harness::TAP reads, I should properly discard
anything which is not a plan, test or diagnostic output. However, test failure
output and programmer supplied diagnostic output need to be disambiguated or
diagnostic
On 7/3/06, Ovid [EMAIL PROTECTED] wrote:
- Original Message
From: Michael G Schwern [EMAIL PROTECTED]
Diagnostic information *is* unreliable in TAP.
Do not parse it.
It is now being discarded.
Don't discard it, just pass it straight through.
Consider the use case of wanting to do
On 7/4/06, Ovid [EMAIL PROTECTED] wrote:
Because we're discarding anything which does not look like a plan or a test line
Don't discard them, just pass them through unaltered. Don't want to
lose any information. The /^#/ lines should be marked as comments.
Anything else is marked as junk but
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 it.
We need a new wiki. schwern.org is too
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
getting a proper domain/uri for it later.
On 7/5/06, Jonathan T. Rockway [EMAIL PROTECTED] wrote:
The thing about using MediaWiki is that it's not written in Perl. Not
that PHP is bad (ok, yes it is bad...), but doesn't it send some sort of
negative message when Perl QA doesn't use a Perl-based Wiki?
Do I worry that qa.perl.org is
On 7/5/06, Tyler MacDonald [EMAIL PROTECTED] wrote:
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
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.
Its a wiki. Go nuts. Err on the side of editing rather than doing
nothing. Not sure if something should go on the wiki?
On 7/5/06, Jonathan T. Rockway [EMAIL PROTECTED] wrote:
1) How would this proposed module benefit the perl community? Why
can't you fix things in Test::Harness and send the patch in? If you fix
deployed modules, everyone wins. If you write your own module, it sits
on CPAN unused.
What
On 2/9/06, Geoffrey Young [EMAIL PROTECTED] wrote:
This works:
yes, excellent randy. thanks for that. it still seems a little hackish but
that's ok - hackish works for me if it means I can do what I want and nobody
else needs to do extra work :)
I made some tweaks to your format and added a
On 7/1/06, Michael G Schwern [EMAIL PROTECTED] wrote:
As my flight is delayed I'll try to make a stab at posting up the basic design.
The whole point of replacing the Perl QA wiki was to have a public
place for the TAP::Harness design to live. :)
http://perl-qa.yi.org/index.php/TAP::Harness
On 7/6/06, Steffen Mueller [EMAIL PROTECTED] wrote:
Versions of Module::Install 0.61 do not work on the current ActivePerl
release 5.8.8 build 817.
What's broken and why suddenly 5.8.8?
On 7/3/06, Jonathan Rockway [EMAIL PROTECTED] wrote:
If you wanted to truly please DJB (with his don't parse mantra), then
you could open two extra filehandles, one for 'ok' and one for 'not ok',
and print the number of the test mod 256 (i.e. one byte per test, no
newline; just the byte) to each
I propose that we all avoid grabbing the juicy names in the top level
TAP namespace, such as TAP::Grammar, TAP::Parser and so on. This
avoids one module getting the special status of being the
TAP::Parser. AKA The CGI.pm problem. Sort of declare a namespace
Antarctic Treaty.
For example, I'd
Folks should read the fascinating document which is the LEGAL file
which comes with the Ruby source code.
http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/ruby/LEGAL?rev=1.12.2.2;content-type=text%2Fplain
The Ruby source contains not one, not two, but SIXTEEN different
licences including the
On 7/7/06, chromatic [EMAIL PROTECTED] wrote:
I DO NOT WANT TO RELICENSE YOUR CODE.
It is a huge maintenance burden.
It creates confusion for developers, who need to decide which version to
patch.
It creates confusion for users, who need to decide which version to use.
You can't reuse
On 7/7/06, Ovid [EMAIL PROTECTED] wrote:
This long-winded (as usual) explanation brings me around to my actual question: is
there really any need to have the lexing and parsing stages clearly delineated? I can't
see why, but from you mentioning several times that that's a parser's job, not
On 7/8/06, Ovid [EMAIL PROTECTED] wrote:
Any text after the test number but before a # is the description of the test
point.
From my observations of test behavior, the shouldn't that be the following?
Any text after the test number but before *an unescaped* # is the description
of the
I am declaring this topic closed on this mailing list. It has sucked
down too much time and energy and generated too much heat and no
light. It has nothing to do with Perl QA. Please take it somewhere
else.
Please do not reply to this thread with anything but the location of
where you intend
Holy crap, its a Test::More release!
I'm sure there's much more important things which need fixing then
what's in this release, but these were sitting around in the repo and
I want to get back into the swing of regular releases.
0.63 Sun Jul 9 02:36:36 PDT 2006
* Fixed can_ok() to
The PITA/TestBuilder2 BoF at YAPC::NA (which spent most of its time
talking about TAP) sketched out a syntax for parsable TAP diagnostics.
not ok 2 - omg t3h sooper test!!1!
file:foo.t
line:45
description: omg t3h sooper test!!1!
got: this
expected:that
On 7/10/06, Ian Langworth [EMAIL PROTECTED] wrote:
These diagnostic keywords seem to blend too much into the rest of TAP.
Look at it in a fixed-with font, if you're not already, and it might
stand out better.
Also consider that with the next gen TAP parsers, enhanced TAP
displays should be
On 7/10/06, Pete Krawczyk [EMAIL PROTECTED] wrote:
I would be concerned about got or expected including embedded
newlines, such as:
is($mech-content,$expected_page,Web page content matches what's expected);
even with a delimiter such as Ian suggested. How would this handle that?
YAML has
On 7/15/06, Ovid [EMAIL PROTECTED] wrote:
Just a thought:
use Tests qw/
Exception
Differences
/;
Have it import those modules and check for sub conflicts.
This doesn't really buy you anything over:
use Test::Exception;
use Test::Differences;
That already warns on import
On 7/15/06, Ovid [EMAIL PROTECTED] wrote:
I don't particularly like that this is a silent failure, but I'm not sure of a
robust way to fix that. In any event, I reread the docs a couple of times
before I realized I was being stupid. That suggests to me that this little nit
could be
On 7/15/06, Jonathan Rockway [EMAIL PROTECTED] wrote:
What's the reasoning behind accepting an array, anyway?
Convenience. You almost always use can_ok() with a list of methods.
It also makes calculating the plan a little easier for it to be one
test.
I recall waffling around on the
On 7/15/06, Jonathan Rockway [EMAIL PROTECTED] wrote:
Worse, it's inconsistent with the rest of the API:
ok$foo == $bar, $REASON;
is$foo, $bar, $REASON;
is_deeply $foo, $bar, $REASON;
And then this:
skip $REASON, $num;
Sadly, it would be hard to change that since so many
Miyagawa noticed that the changes to Test::Builder::Tester's
test_fail() in 0.63 broke Test::Exception and probably plenty others.
The change broke backwards compat and should not have been accepted.
So here's an emergency release to fix that.
0.64 Sun Jul 16 02:47:29 PDT 2006
* 0.63's
On 7/17/06, demerphq [EMAIL PROTECTED] wrote:
Just to clarify, my main point is really that test names should be
mandatory. The fact that making them mandatory also solves other
problems is to me mostly a nice bonus. What I really want is that when
I try to build something and it fails test that
On 7/17/06, A. Pagaltzis [EMAIL PROTECTED] wrote:
so by now we've had quibbles about the irregularity of `skip`,
`can_ok` and `isa_ok`, and a suggestion that the test name always
go first.
This puts the emphesis on the wrong thing. The point of the test is
the test, not the description.
On 7/18/06, Randy W. Sims [EMAIL PROTECTED] wrote:
The dependency on the stream interface is not necessarily bad; it would
just mean pushing the decoupling up a level: let the stream abstract
away the details of reading bits from some source. Your above example
would allow:
my $parser =
On 7/20/06, Gabor Szabo [EMAIL PROTECTED] wrote:
As this is a live site with user created pages I don't know up front how
many pages I am going to test thus I don't know the number of tests
before I run them.
On the other hand I can count them during the test and can tell
Test::More that I was
On 7/20/06, Tyler MacDonald [EMAIL PROTECTED] wrote:
Exactly. :-) Take a look at, for instance, IPC::Run's test cases...
an array of sub{} blocks, some of which get skipped over on certain OS'es.
It'd be really easy to accidentally put to ok()'s in one sub{} block and
screw up the count.
On 7/20/06, Gabor Szabo [EMAIL PROTECTED] wrote:
If I am not mistaken the problem with no_plan is that the test script
might exit before actually running all the tests you wanted and Harness
won't notice it.
That's what I wanted to avoid.
So maybe if there was a mode where Test::Builder did
On 7/20/06, Gabor Szabo [EMAIL PROTECTED] wrote:
If I am not mistaken the problem with no_plan is that the test script
might exit before actually running all the tests you wanted and Harness
won't notice it.
PS In all my years of testing I have never been bitten by this in the
real world
On 7/20/06, A. Pagaltzis [EMAIL PROTECTED] wrote:
use Test::More;
plan tests = my $tests;
{
require_ok( 'MyModule' );
my $obj = MyModule-new();
isa_ok( $obj, 'MyModule' );
}
BEGIN { $tests += 3 }
Pretty sneaky. This is now in the FAQ.
On 7/21/06, Adriano Ferreira [EMAIL PROTECTED] wrote:
If I run this script
use Test::More;
plan tests = 2;
BEGIN { use_ok( 'My', 'foo' ); }
ok(1);
is(foo, 1);
I got the output, which says nothing about the use_ok. It is not
counted as a test, it does not ruin the plan,
(I'm going to s/functional testing/acceptance testing/g here because
to me there's not a whole lot of difference between a unit test and a
functional test).
Both your reasoning are correct. The question is now one of practicality.
For one, its never just one or the other. Its not acceptance
Since this is a really common discussion, I've summed it up on the Wiki.
http://perl-qa.yi.org/index.php/Acceptance_vs_Unit_Tests
On 8/15/06, Adrian Howard [EMAIL PROTECTED] wrote:
To be honest, I'm not entirely sure that I could come up with a
really convincing argument for TAP for an audience using JUnit,
TestNG and similar...
Do we have a convincing argument? Maybe I'm just being overly
pessimistic today :-)
The
http://www.pobox.com/~schwern/src/Test-Simple-0.64_01.tar.gz
This release of Test::More is primarily to remove support for threads in 5.8.0.
Threads are just too buggy in that version and I'm tired of getting bug
reports about the same failing test from 5.8.0 users.
There is also a minor
Ovid wrote:
- Original Message
From: ivorw [EMAIL PROTECTED]
I've had similar issues with test output out of sequence, especially when
I pipe the output into more or tee (sometimes 21 helps, but not
always).
What about an optional environment variable which forcess *all* output to
Geoffrey Young wrote:
$ perl -MTest::Harness -wle 'runtests @ARGV' ~/tmp/stdout.t
/Users/schwern/tmp/stdoutdubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 1
Failed 1/1 tests, 0.00% okay
Failed Test
Shlomi Fish wrote:
t/sample-tests/todo in the Test-Harness distribution reads:
print DUMMY_TEST;
1..5 todo 3 2;
ok 1
ok 2
not ok 3
ok 4
ok 5
DUMMY_TEST
As one can see, the 1..5 plan is followed by the todo 3 2; directive.
This is supposed to indicate something about plan ahead todo tests.
Ovid wrote:
$ perl -MTest -e 'plan tests = 10, todo = [2,4];'
1..10 todo 2 4;
As there are quite some test scripts out there that use it, staying
compatible with it sounds like a prerequisite.
By it do you mean Test.pm or Test.pm's todo feature? The former I can
believe. The latter... I'd
Geoffrey Young wrote:
and
seems a little broken so I doubt anyone's using it,
I use it every day, and it's not broken for me...
By broken I mean I was surprised to find the behavior of Apache::Test changed
by changing the backend. I would have expected the interface to remain the
same.
Yitzchak Scott-Thoennes wrote:
Is the avoid mixing warning out of date? Or in accord with future TAP
plans?
That dates back from the original version of Test::Builder in 2001.
Test::Harness has handled no numbers and mixing of with and without numbers for
as long as I know, but not always
jerry gay wrote:
as i work on parrot, i happen to know a few language designers. i know
they're interested in providing feedback on the proposed TAP changes, but
(perhaps because i'm new to the list) i don't see a good thread to point
them to. is there a summary of changes, or something i've
Thanks for the updates, Thomas. And now on with the complaining!
Thomas Klausner wrote:
- has_example
An optional metric that checks if the author included a dir called
'eg|ex|example(s?)' which in turn includes at least on *.pl
IMO examples in an example directory are a detriment, not
Torsten Schoenfeld wrote:
Here's an initial attempt at a Gtk2 interface.
From running it against a few test suites and getting some strange
results, it seems like TAPx::Parser doesn't like lines like
ok 3 # comment
It flags the corresponding result as being of type unknown.
And its
Adrian Howard wrote:
Maybe this is the right time to think about mechanisms supporting
different versions of the TAP protocol?
http://perl-qa.yi.org/index.php/TAP_version
Ovid wrote:
- Corrected the grammar to allow for a plan of 1..0 (infinite
stream).
1..0 is currently used as part of the skip all syntax.
1..0 # skip Because I said so
Perhaps an infinite stream is just 1.. ?
Torsten Schoenfeld wrote:
Yeah, this is hand-rolled stuff. One example:
http://search.cpan.org/src/TSCH/Glib-1.140/t/7.t
As the comment in there says ...
we do not use Test::More or even Test::Simple because we need to test
order of execution... the ok() funcs from those modules
Thomas Klausner wrote:
The one advantage of dedicated examples for me is that I can take that
example file (mostly downloaded from search.cpan.org), run it, modifiy
it, run it etc.
Cutting and pasting from the docs works as well, no network required. And its
going to be the example for the
Ovid wrote:
I've run into a possible bug with TAPx::Parser. According to
http://search.cpan.org/dist/TAP/TAP.pm#The_plan:
The plan cannot appear in the middle of the output,
nor can it appear more than once.
I'm getting parse errors because comments are output after the plan:
Gabor Szabo wrote:
Going along the path of testing the examples in my distribution,
I think it could be generalized. What do you think about this?
I think putting the expected output into files fractures the test so that its
not obvious from just looking at the test what's going on. You have
Adrian Howard wrote:
On 13 Sep 2006, at 05:37, Michael G Schwern wrote:
[snip]
(For the sarcasm impaired, if you're just going to store the whole
post-install source tarball you might as well just grab it from CPAN
again)
[snip]
Isn't the post-install source tree potentially different
Adam Kennedy wrote:
Hmm, that would waste a lot of disk. Maybe we could cache the
tarballs somewhere. Maybe on the network or even Amazon S3. Some
sort of big repository of modules. We can call it the Network of
Archived Postinstall Crap, NAPC for short!
This same argument applies to
Adam Kennedy wrote:
I'm find with adding an additional environment variable though for the
packaging state. But please lets not decide on anything right now,
AUTOMATED_TESTING is already a sub-optimal name, I'd rather make sure
that the EU::MM, M:B and M:I modules all agreed on a single
Ovid wrote:
- Original Message
From: chromatic [EMAIL PROTECTED]
ok 1
not ok 2
1..2
# this comment is acceptable
... but what about this?
Shouldn't that last line always be an error wherever it occurs?
For purposes of forward compatability, it's been my
Ovid wrote:
The corrected TAP grammar:
digit ::= [:digit:]
character ::= ([:print:] - \n)
positiveInteger::= ( digit - '0' ) {digit}
nonNegativeInteger ::= digit {digit}
tap ::= plan tests | tests plan {comment}
plan::= '1..'
Adam Kennedy wrote:
I'm not suggesting we test against the post-make code, but if we keep
everything, we can be fairly certain we still have any data files or
other things that are needed to support the testing.
Now we rerun the test suite, but without including blib.
And you get a full
Ovid wrote:
- Original Message
From: Adam Kennedy [EMAIL PROTECTED]
Please excuse the stupid question, but is there any chance this could
use Wx instead of Tk, since Wx installs from CPAN cleanly everywhere now
(I think) and Tk doesn't seem to install properly.
I finally gave
Ovid wrote:
The reason you see descriptions starting with a hyphen in Test::More style
output is because people do stuff like this:
ok $foo, '3rd test passed';
And you don't want to risk that leading digit confusing the parser.
Actually its there because I thought it made it easier to
chromatic wrote:
On Thursday 14 September 2006 13:14, Ovid wrote:
What's 'bonus'? I haven't figured that out yet.
That should be the number of successful TODO tests. If it's not, I have no
idea.
Also, I never tracked the exit status of the tests. Frankly, I never used
that number
Chris Dolan wrote:
token description { after \h -[#\n]+ }
The description can't start with a number if there is a test number:
isn't?
token description { after \h -[#\n\d] -[#\n]* }
Adam Kennedy wrote:
It might be worth running Perl::MinimumVersion over the codebase real
quick.
It has all the obvious stuff coded into it (like warnings and qr//)
already.
Swanky!
Some minor nits (-v not documented, documented output not the same as actual
output). And I can think of a
Adam Kennedy wrote:
utf8.pm was added in 5.6.0 not 5.8.0
I think that was more of a case of utf not working WELL until in the 5.8
series.
I'm not sure on the details though.
All of Unicode didn't work well until 5.8, but do you want to encode such
things? If you go down that route
Ovid wrote:
The following line is giving me pause:
ok 9 Elegy 9B # TOdO
That's an 'unexpectedly succeeded' test ('bonus', in the Test::Harness
world).
I agree bonus is not a very good term. It was what was in the TH code when I
dug out the TODO functionality.
Right
Ovid wrote:
- Original Message
From: Adam Kennedy [EMAIL PROTECTED]
What I find surprising is the concept that a TODO test is assumed to fail.
If I mark a test (block) as TODO, I would have thought by flagging some
tests as not done yet then for the purposes of PASS/FAIL I don't
Fergal Daly wrote:
I'm agnostic on whether it should pass or fail (perhaps trying to
wedge 3 states into 2 is root of the problem) but to me, a passing
todo test implies that the author doesn't understand either his code
or my environment. Neither are good signs for reliability of the
module,
Ovid wrote:
And here's the answer:
I'll add a feature to TAPx::Parser which will allow one to choose whether or
not 'ok # TODO' passes.
Please don't.
1) It breaks TAP.
TODO and SKIP tests pass. They've always passed. There's no good reason to
change this. Breaking protocols is bad,
The tenor of the opinions in the passing TODO tests bother me a bit. It seems
folks have forgotten why the CPAN installation chain exists. Especially the
assertion that its perfectly ok for modules to start failing even though
there's nothing wrong with them (unless you raally stretch
Ovid wrote:
So I now have well over 2,000 tests for the parser, but there's a corner case
that's killing me. Test::Harness handles it fine, so I'm thinking that the
TAP specification (and subsequent grammar) is wrong.
In the Perl core, we have t/base/rs.t and on line 129 of that file we
Michael Cummings wrote:
But I cannot stress enough
Stress is bad for you. You really should try calming down, perhaps cut down on
caffeine consumption. Maybe take a short vacation. Reduce the amount of
quoting out of context in your life. ;P
As David pointed out, testing the module and
Given what Ovid said last month about TAP not being about just Perl, I've
started an article on Wikipedia about TAP. Most of the content is taken from
TAP.pod, the Perl QA wiki and my own head.
Edit away.
http://en.wikipedia.org/wiki/Test_Anything_Protocol
Ovid wrote:
- Original Message
From: Michael G Schwern [EMAIL PROTECTED]
foreach $test (11..14) {print ok $test # skipped on non-VMS system\n};
That unescaped hash mark is causing me lots of pain.
Because its not an unescaped hash mark. Its an old school skip directive
Ovid wrote:
- Original Message
From: Michael G Schwern [EMAIL PROTECTED]
In regex terms, a directive is simply
($type, $reason) = /#\s*(\S+)(?:\s+(.*))?$/. TAPx::Parser
can record the type and reason and move along. You might
want to warn about the unknown directive type
demerphq wrote:
I found that the suggested code for saving and restoring STDOUT and
STDERR given in perldoc -f open seems to work OK. This is essentially
what IPC::Run3 is doing -- capturing to an external file and then
reading it back in and making it available.
Yeah, but thats a can of
Fergal Daly wrote:
But there's nothing here for the author to do so it should not be
marked TODO.
Sure there is. They now know Fribble works and can once again start relying on
it.
This should be a skip wrapped in something to test if the installed
version of Fribble works or not.
David Cantrell wrote:
What do people think are *good* tests?
Good tests catch bugs.
This might seem obvious and its probably not what you were asking for, but
you'd be surprised at how often its forgotten in worries about code coverage,
style issues, setup, teardown, portability, black box,
It comes down to this:
SKIP tests are for when it'll never work. Or if you don't care.
TODO tests allow the author to be notified when something that was broken
starts working again. It doesn't matter what that thing is.
If a module you depend on breaks and you want to know when it works
Ovid wrote:
- Original Message
From: Michael G Schwern [EMAIL PROTECTED]
Something to consider in all this is that TAPx::Parser
needs to know to display what goes to STDERR
and suppress what goes to STDOUT. This means
you simply can't mash the two streams together,
you have
Ovid wrote:
Now I have guaranteed cross-platform behavior, STDERR and STDOUT are
guaranteed to be in
synch, this doesn't cause any problems for Test::Harness, I don't need to
fork Test::Builder
and I override one method which has not changed since May 2005.
Unfortunately, I'll have to
Ovid wrote:
From: Michael G Schwern [EMAIL PROTECTED]
I will now break your solution.
use Test;
plan tests = 1;
ok 23, 42;
PHEAR MY MAD HAX0R SKILLZ!
:P
Hmm, interesting. My parser handled that just fine.
Yes, that is interesting. How did it capture the diagnostics going
Michael G Schwern wrote:
Ovid wrote:
From: Michael G Schwern [EMAIL PROTECTED]
I will now break your solution.
use Test;
plan tests = 1;
ok 23, 42;
PHEAR MY MAD HAX0R SKILLZ!
:P
Hmm, interesting. My parser handled that just fine.
Yes, that is interesting. How did
Test-Harness, Test-Legacy, Test and Test-Simple are proving good at beating up
tprove and TAPx::Parser 0.31. I'd suggest running tprove --lib t/*.t in each
of them and watch the fur fly. Sometimes there's failures. Often its
displaying diagnostics which should not be displayed.
The good
[EMAIL PROTECTED] wrote:
I'm very pleased to announce that tidyview is now available from CPAN.
Neat idea, but this is bad:
0 windhund /usr/local/src/CPAN/tidyview-1.09$ sudo make install
Password:
Installing /usr/local/lib/site_perl/VERSION.pm
Like it or not, we have to live with
Randy J. Ray wrote:
While checking the Wiki page recently pointed to, I noticed that several of
the entries under Producers are actually parsers.
Umm, which ones? I guess Test.Simple has a parser.
Its a Wiki. You don't announce that there's something wrong, you just fix it.
Adrian Howard wrote:
On 5 Oct 2006, at 15:11, Paul Beckingham wrote:
Recently I was required to create another flavor of test harness that
runs tests, then captures and stores output.
The nature of my testing means that I am running millions of tests,
and the resultant captured output is
Jonathan Rockway wrote:
I like the YAML syntax, but can we live with:
got: |
this is line 1
this is line 2
expected: |
this is line 1
this is line 2
Instead? That way a real YAML parser can parse the output of TAP, which
could be important for adoption by other languages. Rather
Christopher H. Laco wrote:
While trying to install the latest PPI from svn, I noticed that running
'dmake test' passed, and 'prove -b t/' failed.
As more and more people use Module::Install, it seems more and more
transient build/test related modules are being stuffed in the inc/
directory.
Ovid wrote:
From: Florian Scharinger
I have troubles building Test-Simple-0.64 on a standard SL3 machine:
snip
several threading related tests fail, e.g.:
snip
-bash-2.05b$ perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
From the Test::Simple
Christopher H. Laco wrote:
I'm in the same boat. Recently, I've started testing my environment when
things go wrong. (I blame Andy). I have one test alone that has a test
count of 500,000+. That's a lot of oks to be processed, when I only want
the ones that didn't pass.
Now, add in a few
Paul Beckingham wrote:
I'm with Adrian. Printing out ok 100,000 times shouldn't be a
big deal unless you're reading the TAP via some sort of IP over
clay tablets protocol. But...
My test estimate is two orders of magnitude larger, so it actually is a
big deal to capture and store those
Michael G Schwern wrote:
It does add significant overhead. Here's the example of one of
Regexp::Common's tests.
0 windhund /private/var/local/cpan_shell/build/Regexp-Common-2.120$ time perl
-Ilib ~/tmp/strip_ok t/number/integer.t
1..23534
real0m4.882s
user0m5.469s
sys
Paul Beckingham wrote:
and waiting for the test output/TAP to be parsed takes quite a while.
Just my $0.02 worth.
-=Chris
To each his own, but my thoughts were not that it takes time to parse,
or that there is any unreasonable performance issue here - just that it
is so completely
Jos Boumans wrote:
Hmm, I hope this doesn't mean you plan on removing the 'non-zero exit status
on failed make test'.. that's be a real PITA for automated installers...
No, that is done by Test::Harness dying on test failure.
Neither CPAN nor CPANPLUS are under any obligation to parse their
David Golden wrote:
On 11/1/06, Michael G Schwern [EMAIL PROTECTED] wrote:
Contact all the authors making use of it and suggest they switch to .t
files. Maybe I could throw a warning into MakeMaker. Also a kwalitee
check sounds like a good idea not_only_test.pl or something.
It shouldn't
801 - 900 of 1466 matches
Mail list logo
