Michael G Schwern wrote:
How about
diag Failure\n. Or even levels of keywords debug/info/notice/warning/
err/crit/alert/emerg (stolen from syslog.h).
That's an interesting idea. My worry is making it human readable.
not ok 2
err Test failed in foo.t line 2
err got: foo
err
Adrian Howard wrote:
Maybe use the levels from Log4J, Log::Log4perl, et al?
fatal
error
warn
info
debug
Ok, maybe take that and tailor it more to testing. Here it is in order of
severity. The recommended display level would be warn.
fatal !!!
There's an error in the TAP producer
Lately I've been hammering hard on every TAP proposal asking why this, why not
that, why do you think this, what about that, is this really going to be a
problem, isn't that situation a little far fetched, not that's not going to
work because... and I get really excited and ruthless about beating
A. Pagaltzis wrote:
The most bangs I can count instantly by looking at them is four.
For five bangs and up, all I see is “lots of bangs.” I have to
count character by character to tell them apart. Visually,
I can’t distinguish `fatal` from `fail` at all. Another problem
is that I’d never
Andy Armstrong wrote:
I'm still not clear what this notation provides that we can't do with
the new YAML machine readable diagnostic syntax. What are the supposed
benefits? Concision?
Yeah, brevity. Pretty much. And human readability. YAML is pretty good and
all but some text prefixed with
brian d foy wrote:
if you're going to use a different starting character for these
messages, how about a [ ? Follow the start of the string by a real
word:
not ok 1
[fail] Failed test in foo.t line 2
ok 2
[fatal] WHOA! The fabric of the universe just broke down!
[damn it,
Andy Armstrong wrote:
( I'm going to be calling the YAML diagnostic syntax YAMLish and I
reckon this proposal should be called bang+ :)
I'm calling it the logging proposal for lack of anything better. The bangs
are now gone.
Yeah, brevity. Pretty much. And human readability. YAML is
Andy Armstrong wrote:
On 18 Mar 2007, at 01:19, Michael G Schwern wrote:
[snip]
In the TAP stream the association between a block of YAML and a
particular
test could be made explicit by putting the test number in the block.
not ok 5
---
test: 5
got: 23
Ovid wrote:
Which brings me to my next point: we appear to have no attracted any
people from other programming communities to the discussion about the
next version of TAP, but I hear that some are using TAP::Parser any
way.Does anyone know of groups that are *regularly* using the
Ovid wrote:
Amusingly, when I was at last year's Google Test Automation Conference,
lots of folks were talking about their XML output from their test
harnesses and many of them weren't happy with it (having to wait for a
well-formed XML document sucks, particularly when a human can read the
A. Pagaltzis wrote:
* A. Pagaltzis [EMAIL PROTECTED] [2007-03-18 23:43]:
* Andy Armstrong [EMAIL PROTECTED] [2007-03-18 22:45]:
I volunteer to host it if necessary.
That’s not a bad idea; a dedicated domain for TAP without any
mention of Perl in the name is probably a good marketing move.
I
Andy Armstrong wrote:
On 18 Mar 2007, at 21:12, Michael G Schwern wrote:
Another problem is we're not even on most people's maps. Here's one
example.
http://opensourcetesting.org
Might it be time we start up a TAP-only mailing list? If nothing else it
would unclog perl-qa from those who
A. Pagaltzis wrote:
What did you intend to gain by merging the TAP::Parser list
into the TAP list?
Well, as long as the discussions about TAP remain firmly on the
TAP list, that might be OK. If the TAP::Parser list deals purely
with implementation details that are truly irrelevant to TAP
Mark Fowler wrote:
On 19 Mar 2007, at 13:03, Adrian Howard wrote:
Nope. It's to add some simple YAML-ish output in places to help
clarify things. It's also a very small subset of YAML rather than the
full YAML spec.
See http://perl-qa.yi.org/index.php/TAP_diagnostic_syntax
Why not
Andy Armstrong wrote:
Of course the idea of the YAMLish dialect negates this one somewhat:
JSON is, effectively, a subset of YAML. If your producer emits
JSON then a YAML parser will
read it. The inverse is not true.
I'm still in favour of YAMLish on largely aesthetic grounds but
Andy Armstrong wrote:
On 27 Mar 2007, at 18:16, Gary Hawkins wrote:
What about diag() output.
It goes to STDERR and is therefore not really part of TAP. Many uses of
diag are expected to be replaced by the YAML based mechanism.
To expand on that, the plan is to transition test module
Ovid wrote:
And then, in my tests, I'll have something like:
my $some_class = Test::MockModule-new($class);
$some_class-mock( is_broken = 1 );
# is_broken tests
$some_class-unmock('is_broken');
$some_class-mock( username = 'twinkletoes');
# twinkletoes tests
Ovid wrote:
- Original Message
From: Michael G Schwern [EMAIL PROTECTED]
How does it know when the is_broken tests have finished and the twinkletoes
tests have begun?
First, I think the method name should be 'mock_once' and each sub gets
wrapped with Hook::LexWrap
Matisse Enzer wrote:
What's the current best practice for running a Perl program and getting
a report of all the subroutine calls throughout the life of the program
in the order in which they were called? (as opposed to something like
Devel:Profile which lists all the subs, and how many times
Adrian Howard wrote:
On 31 Jul 2007, at 11:56, Ovid wrote:
[snip]
We can see right away from the report above that Test::Class will cause
many folk's installs to fail since it's not listed as a prereq and it's
possible that SUPER doesn't need as high a version as is listed, though
Andy Lester wrote:
On Jul 31, 2007, at 3:43 PM, David Golden wrote:
* Module::Starter -- Andy wants these tests run by default and he
doesn't seem to be swayed; So people need to fork this and start
advocating for an alternative.
Or maybe it's just not that big a deal.
Once again,
In fact, when a topic degrades to this level on the list go yell about it on
IRC. Email is the worst possible form of communication for this, its
optimized for big, detached speeches. At least IRC is more like a real time
conversation and the five people arguing won't scare off the hundred other
Eric Wilhelm wrote:
Can the responsible parties please cleanup this chain of links and
shutdown/lock [1] the two abandoned wikis?
http://qa.perl.org/ [2] links to:
Ask can fix that. Ask?
http://schwern.org/~schwern/cgi-bin/perl-qa-wiki.cgi links to:
Fixed that to point straight to
demerphq wrote:
So assuming we want to add new modifiers (we kinda do) how should this
be addressed? Both going forward and dealing with legacy code.
My first inclination is that what you want is a way to get at the underlying
structure of the regex so you can query what flags there are on it
David Cantrell wrote:
David Golden thought that this might be more useful as a web thing than
done by email by the CPAN testers, so I hacked something up:
http://cpandeps.cantrell.org.uk/
It's a foul, disgusting hack. If anyone wants to make it less sucky (eg
to work off local databases
Adriano Ferreira wrote:
Testing some Author stuff would be rarer than having author tests. So
maybe we could standardize on something like t/author and when other
value is desirable, a key/value pair may be specified in META.yml (and
in Makefile.PL/Build.PL).
# META.yml
---
# the
Cyberiade.it Anonymous Remailer wrote:
there's a lot of questionable modules being uploaded to CPAN
which create top-level namespaces, very often not even being
self-explanatory. it would be nice to add points for
modules which have registered namespaces. this should encourage
more
Ovid wrote:
After doing a bit of thinking about this and chatting with Andy
Armstrong about this, I've realized that much of the current thought
about the TAP diagnostics is wrong. We already have much of what we
want in the TAP line above the diagnostics so there's no need to be
redundant.
Ovid wrote:
Schwern: you're specifically copied on this as you maintain
Test::Simple. If we get this working, how would you feel about a patch
to Test::Simple that makes this automatically incorporated into new
test suites which upgrade Test::Simple? The obvious problem is that
this would
demerphq wrote:
On 9/1/07, Fergal Daly [EMAIL PROTECTED] wrote:
On a tangent, I think using quotes is important otherwise you end up output
like
wanted: elbow
found: elbow
when what you really needed was
wanted: 'elbow'
found: 'elbow '
No need to quote
Ovid wrote:
--- Eric Wilhelm [EMAIL PROTECTED] wrote:
I'm not sure the YAML spec distinguishes between string and number
when
the string is a number.
$ perl -e 'use YAML; warn YAML::Dump([3,3]);'
---
- 3
- 3
$ perl -e 'use YAML::Syck; warn YAML::Syck::Dump([3,3]);'
---
Ovid wrote:
--- Michael G Schwern [EMAIL PROTECTED] wrote:
As Test::More cannot have any dependencies, I'd rather incorporate
TAP diagnostic functionality directly into Test::Builder. Besides,
spitting out some YAML isn't hard.
It turns out to be a fair bit harder than it appears
demerphq wrote:
On 9/2/07, Michael G Schwern [EMAIL PROTECTED] wrote:
The first is a single ISO 8601 datetime. The latter is an ISO 8601 date and
an ISO 8601 time separated by a space. Two data fields instead of one. So
it's all kosher, we just have to specify that's what we're doing
Fergal Daly wrote:
diagnostic( {
found = $found, # can be stand-alone
wanted = $wanted, # must always be present with 'found'
display = $display, # optional human-readable presentation
extra = $extra, # anything else. Useful for custom harnesses
meta= 0,
Fergal Daly wrote:
I'm assuming here that test modules will provide these diagnostics in
a similar way to the old style, something like:
my $TB = Test::Builder-new()
sub my_test {
blah();
$TB-ok();
if ($TB-can(verbose_diag) {
$TB-verbose_diag({...});
} else {
Eric Wilhelm wrote:
# from Andy Lester
# on Sunday 02 September 2007 08:53 pm:
When are we gonna put 2.99x up?
I dunno. Are we waiting on t/compat/010-failure.t to be done? Seems to
work now.
And TH_TODO still has these (non-Wishlist) bugs listed as open.
- [ ] 8767[PATCH]
Gergely Brautigam wrote:
I'm sorry as a beginner on this list.. Can I ask in what these modules are
written? These modules are in Perl aren't they? Are there any written in c++?
Like Win32 modules?
Yes, they're written in Perl. Yes, it will run on Windows.
The nice part about TAP::Parser
Ovid wrote:
Andy (Armstrong), aside from the fact that we now know that it fails
miserably on VMS, do you know of any show stoppers or potential
embarrassments?
(The only reason I mention potential embarrassments is that CPANPLUS
and Module::Build have left such a bad taste in many people's
Ovid wrote:
--- Michael G Schwern [EMAIL PROTECTED] wrote:
How
ironic. It's a silly concern, I know :)
Wringing your hands
over perception issues defeats the point.
Did you see the bit where I wrote It's a silly concern? I *know*
this.
I know. You just need an ass kicking
A. Pagaltzis wrote:
Is it possible to force this in tandem? Ie. when one of the keys
has to be quoted, the other is always quoted also? Because I’d
hate to see this:
wanted: elbow
found: 'elbow '
For simple cases like this one it’s livable, but if the data gets
more complex,
A. Pagaltzis wrote:
* Michael G Schwern [EMAIL PROTECTED] [2007-09-02 09:32]:
What you're thinking of is RFC3339 which is more describing a
state of affairs on the Internet then anything else.
Actually RFC 3339 date and time formats are best practice at the
IETF/IESG.
I got RC 3339
Andy Armstrong wrote:
On 4 Sep 2007, at 22:41, Ovid wrote:
What do you think of this?
http://testanything.org/wiki/index.php/TAP_datetime
Works for me.
Yup, looks fine.
Maybe we should start noting this on the wiki? Sign proposals with a
(Mediawiki signature).
Gabor Szabo wrote:
I would like to compare data structure in some non-test code.
Test::Deep seems to give all the features I need, except that it is
integrated with
the testing framework.
How could I use that or what else should I use to compare two deep
data structures?
Here's how to
Michael Peters wrote:
Ovid wrote:
Thanks for reminding me. Another bit of meta-information that should
be optionally supported in the TAP YAML output is duration. If one's
comparing the behavior of a test suite over time, some might find it
beneficial to know that they've added 10% more
A. Pagaltzis wrote:
If they're really not useful and just complicate matters I'm
quite open to being convinced otherwise.
OK; the goal here, I think, is to make TAP as simple as possible
to generate as well as consume, without limiting expressiveness
unnecessarily.
Yep, we're on the same
A. Pagaltzis wrote:
I don’t think you’re overly conservative when it comes to app
data, but I agree with Ovid that this is bad separation of
concerns. How dates in app data are handled should be up to the
app to define. I think we should restrict this proposal solely to
datetimes in TAP
A. Pagaltzis wrote:
SHOULD is costly and should be avoided in favour of MUST or MAY
wherever possible – we had this discussion we had frequently in
the Atom WG. Over time, given enough implementations, any given
SHOULD tends to be treated as either a MAY or a MUST anyway.
That reasoning
Ovid wrote:
Whoa! I missed a memo and now I'm confused. I did think that a lot of
this fuss over the date YAML meta information in TAP was going on a
bit, but small details can be important. However, date YAML diagnostic
information (we need formal names to distinguish between those two)
Geoffrey Young wrote:
Scott McWhirter wrote:
This would be easy to do in Test::Builder within Test::Builder::ok by
making it call $Test-BAIL_OUT();
Then at least you would get it across all Test::* modules.
yeah, that's what I was implying in my followup message.
the attached patch
A. Pagaltzis wrote:
* Michael G Schwern [EMAIL PROTECTED] [2007-09-07 14:40]:
I'm down with changing it to MUST for TAP meta and MAY for
diagnostics.
Works for me.
Done.
--
Stabbing you in the face for your own good.
Matisse Enzer wrote:
A side-note to keep in mind: If we every want to be able to convert TAP
to the XML format produced by the JUnit ant task (this way for example
CruiseControl could more easily read the results of Perl tests) then it
becomes desirable to get timing info for each perl test -
Andy Armstrong wrote:
On 8 Sep 2007, at 11:21, Michael G Schwern wrote:
Is this a time stamp or the elapsed time for a test? The former is
pretty
easy, just add to Test::Builder::ok(). The latter is not. Perl tests
don't
have any clearly defined start or end for a given test like JUnit
Matisse Enzer wrote:
There certainly is a mapping problem and I don't have a perfect
solution, and enabling Perl test output to be understood by
CruiseControl (for example) is a valuable thing, in my opinion.
Seems to be, knowing nothing about CruiseControl, that rather than trying to
match
Andy Armstrong wrote:
On 9 Sep 2007, at 22:04, Ovid wrote:
As I recall, we've hit the same problem with another module (POE?) and
I'm thinking that extending the TAP grammar here might be the key.
Specifically, consider this:
1..0 # SKIP some reason
The '1..0' is 'skip all' and the
Michael Kernaghan wrote:
While you are at it would you care to try to install modules from CPAN
onto Active Perl running on Vista? It just seems a world of grief;
although identical installs are great under XP. I just flat gave up
using Vista for Perl. I feel sad, but what can one do?
If
Thomas Klausner wrote:
On Mon, Sep 10, 2007 at 11:10:25PM +0200, Anonymous wrote:
also, would it make sense to have a test to check for warnings
when warnings are enabled globally? many modules do not enable
warnings, but when you use those modules and run the script
with -w, it's possible
Thomas Klausner wrote:
I'm not sure if the problem is caused by some dists liek Number::Phone,
or by Pod::Simple::Checker (YAML for sure is causing the segfaults, but
I'd definitly want to correct the data, too)
I've put one of the problematic files up here:
http://www.pobox.com/~schwern/src/Test-Simple-0.71.tar.gz
The big change here? No more sort_bug.t. Bye bye 90% of my spurious bug
reports. It was testing two deprecated functions and tended to hit bugs in
threaded perls that I can't fix and the user doesn't care about.
I replaced with with a
Test::More 0.71 fixed a subtle bug where a call to use_ok() inside a BEGIN
block without a plan would be silently ignored. That is...
use Test::More;
BEGIN { use_ok('Exporter') } # for example
plan tests = 1;
pass();
would pass when it should have failed.
Jerry D. Hedden wrote:
Michael G Schwern wrote:
http://www.pobox.com/~schwern/src/Test-Simple-0.71.tar.gz
BTW, when to you plan to submit a patch for this against blead?
Magic p5p fairies usually take care of that.
--
Stabbing you in the face so you don't have to.
Rafael Garcia-Suarez wrote:
And tests now pass with following change.
It takes care of
a/ pushing the right dirs in @INC when running in the perl core test suite
b/ fixes the $VERSION of Dummy.pm. Apparently bleadperl comes with
another version of Dummy.pm than Test::Simple don't ask
This release unfixes a bug. 0.71 fixed a bug where if you ran a use_ok()
inside a BEGIN block without a plan it would silently fail and the test would
continue. For example...
use Test::More;
plan tests = 10;
BEGIN { use_ok(Some::Module) }
It looks like you planned
Ovid wrote:
--- Michael G Schwern [EMAIL PROTECTED] wrote:
Because of this I'm TEMPORARILY rolling the fix back at least a week
to give
CPAN authors a little breathing room to make their fixes. The fix is
usually to plan in a BEGIN block.
This has happened a couple of times now. Why
Ovid wrote:
For something as high profile as Test::Simple, it would get much more
exposure than most modules. Plus, there wasn't much in the changelog
which suggested this was a rush OMG Must Deliver Now sort of change (it
had been six months since the last release).
I get a bug up my ass,
This week's Perl 5 Wiki topic improvement drive is...
Recommended Modules For Testing
http://www.perlfoundation.org/perl5/index.cgi?recommended_modules_for_testing
Right now there's only TWO modules listed. I know a few people have written
good testing modules out there.
David Cantrell wrote:
Michael G Schwern wrote:
This week's Perl 5 Wiki topic improvement drive is...
Recommended Modules For Testing
http://www.perlfoundation.org/perl5/index.cgi?recommended_modules_for_testing
It appears that I can't make any changes without registering for yet
Salve J Nilsen wrote:
- Set up some kind of syndication feed [RSS, Atom] [somewhere sensible]
where one can read which distributions currently have a pre-release
status. The feed might be called NEED TESTING or something like that.
Make this feed visible on central Perl-related websites
Greg Sabino Mullane wrote:
I just released Bucardo, a multi-master replication system for Postgres.
It has a fairly intense test suite, and I was developing it, I ended up
writing Yet Another Test Counter. At some point, I decided to turn it
into a proper module. Here's the POD page:
Zaven Boni wrote:
Hello list,
My team at Data Domain (NASDAQ: DDUP), the leader in de-duplicating
storage systems, is looking for an engineer with solid Perl skills as
well as a system performance measurement and tuning background. We are
part of the development team which builds the DDOS
Graham TerMarsch wrote:
As a dumb alternative... what about explicitly listing M::B as a build
dependency? Would that trigger CPANPLUS into installing it and then
restarting the build?
I don't know what CPANPLUS does with build_requires. It'll probably balk
about missing
Graham TerMarsch wrote:
On Wednesday 26 September 2007 3:41 pm, David Golden wrote:
I don't think Module::Build can be a build_requires. I think it has to
be a configure_requires. (Not that support is widespread yet.)
On 9/26/07, Michael G Schwern [EMAIL PROTECTED] wrote:
Graham TerMarsch
Greg Sabino Mullane wrote:
Michael G Schwern asks:
What's wrong with no_plan? Why go through backflips to
automate counting the tests when you can just not count
them? Seems needlessly officious.
I seldom run the whole test suite at once, but only parts I care about
at the moment, so
Greg Sabino Mullane wrote:
On Fri, 2007-09-28 at 17:09 -0700, Michael G Schwern wrote:
It's also nice to see how far along we are with a running
tally, when I check back in on the running tests.
How do you accomplish that?
Not sure what you mean. Toggle back to the terminal window
Andy Lester wrote:
On Fri, Oct 05, 2007 at 11:22:57AM -0500, brian d foy ([EMAIL PROTECTED])
wrote:
Do you mean that Test::Harness 3.0 won't have it but it will still be
there in earlier releases, or that you're going to remove any trace of
it from CPAN so it looks like it never existed?
Eric Wilhelm wrote:
# from Michael G Schwern
# on Monday 15 October 2007 18:00:
We're not going to retroactively remove it from the 2.x series. 3.0
and beyond will not have straps.
To clarify further, upgrading from TH 2 to TH 3 will not break Straps.
not break in what sense? From my
Geoffrey Young wrote:
Honestly, just convert to TAP::Parser. Straps has no future.
Apache-Test subclasses Straps to override _command_line() and provide
php as the test caller (so you can run t/foo.php with php instead of perl).
unfortunately for us, the magic required for this to work
chromatic wrote:
On Tuesday 16 October 2007 05:18:40 Michael G Schwern wrote:
Honestly, just convert to TAP::Parser. Straps has no future.
It has a zombie future. You can't remove it for TEN YEARS because it's in
the
core and people with government contracts rely on it.
Page one
Andy Armstrong wrote:
On 16 Oct 2007, at 20:04, Michael G Schwern wrote:
If somebody REALLY cares they can gut it to use TAP::Parser so it gets
future
bug and feature fixes. But that's like putting rocket engines on a
blimp.
To be honest when I started working on Test::Harness 2.xx
Hi, you're getting this mail because your CPAN distribution makes use of
Test::Harness::Straps (or you're subscribed to perl-qa).
Test::Harness version 3 will not include Test::Harness::Straps. It was an
experiment, it didn't work out. Sorry. Current users of Straps are
encouraged to instead
Eric Wilhelm wrote:
/usr/local/sbin/mbBuild is:
#!/bin/sh
./Build $@
^^
That should be $@ or else it will get confused by spaces.
On a related note, that sort of thing is generally useful for those of us who
find typing ./Build just a little more annoying than make. I have
demerphq wrote:
On 10/19/07, A. Pagaltzis [EMAIL PROTECTED] wrote:
* demerphq [EMAIL PROTECTED] [2007-10-19 18:50]:
How does one use this then? Where is it documented?
http://module-build.sourceforge.net/META-spec-blead.html#configure_requires
So how do i use this with MakeMaker?
Step One:
chromatic wrote:
This is a specific sort of failure, and as far as I'm concerned it is an
improperly configured machine. I'm not going to include a redundant
Makefile.PL just to support people who don't upgrade their tools. It's
no different than not supporting perl 5.005.
I believe Eric is
nadim khemir wrote:
I spend a rather large amount of time writing and running tests. There are a
few things that could be better. I either don't know how or it may not
possible. I thought we could share some of questions and ideas that can make
working with tests more pleasent. This should
This is an announcement that my modules will no longer try to be backwards
compatible with 5.5.x. This includes ExtUtils::MakeMaker and Test::More.
Toolchain modules will now target 5.6.0. Modules not part of the build
toolchain will be moving up to 5.8.0.
This doesn't mean I'm going to go
brian d foy wrote:
Fair enough. Can you make a list of the last versions of all of those
that should work with Perl5.005? I suppose that's the current list
right now.
Pretty much. If anyone wants to put in the effort to make such a list they
can, knock yourself out.
--
...they shared one
Gabor Szabo wrote:
I would suggest for those who are really interested in OPS (Old Perl Support)
to run the tests of the module(s) on OP and report them to CPAN Testers.
That way we'll be able to fetch the
latest version passing its test on OP for every module on any specific OP
right from
Slaven Rezic wrote:
Michael G Schwern [EMAIL PROTECTED] writes:
Why make this change now? I've always been frustrated at being hamstrung
from
using new features of perl. The Perl Survey results is what pushed me over
the edge. [1] Only 6% of the respondents say they used 5.5.x
Andy Armstrong wrote:
I've added logic that produces output like this:
13:54] andy $ prove t/sample-tests/skipall t/sample-tests/
skipall_nomsg t/sample-tests/simple
t/sample-tests/skipall..skipped: rope
t/sample-tests/skipall_nomsgskipped: (no reason given)
Matisse Enzer wrote:
I am looking for a way to run a fully-automated CPAN build (using
CPAN::Shell) of a local Perl module and its dependencies, but, I need to
make REMOVE some directories from the compiled-in @INC during the build
process.
While it is not documented, you can override what
As interesting / important as all this might be or might not be, it has
nothing to do with quality assurance. Take it elsewhere. Perhaps Groklaw,
they might actually have some legal knowledge.
And please don't replace the argument with an argument about how this is
somehow related to QA.
Andy Armstrong wrote:
It is done :)
http://hexten.net/tapx/r867/Test-Harness-3.04.tar.gz
or
svn co http://svn.hexten.net/tapx/trunk
=head2 Arguments to Tests
It is possible to supply arguments to tests. To do so separate them from
prove's own arguments with '--'. For example
Andy Armstrong wrote:
On 29 Nov 2007, at 02:17, Michael G Schwern wrote:
Why isn't this just:
prove -v t/mytest.t --test_args='--url http://example.com'
It's clear, it's unambiguous, it allows -- to mean what it's supposed
to mean.
I agree re the semantics of '--' - but I'd rather
Eric Wilhelm wrote:
# from Michael G Schwern
# on Wednesday 28 November 2007 20:11:
There's the additional problem that it restricts the test arguments to
only be allowed at the end of the prove command line. This means
switch ordering is important, which will lead to problems
Andy Armstrong wrote:
Will the sky fall and babies cry if we go with '--'? I would hope not.
It closes off the conventional method of passing in files that look like
switches. So yes, that hunk of sky will fall.
Let's have a quick show of hands and move on, eh?
[ ] --
[X] something else
Andy Armstrong wrote:
I'd like
# Run all tests
$ prove --state=save -rb t/*.t
# Re-run failures from above
$ prove --state=fail -rbv
# Re-run failures and remember failures
$ prove --state=save,fail -rbv
Using the third form repeatedly would run only the test programs that
failed
Andy Armstrong wrote:
Why so verbose?
Aristotle's '::' suggestion is my favourite. It's syntactically clean.
It's visually distinct from other switches - so you can easily see that
something special is happing. It's short.
And without context it's totally void of meaning. Someone hit it on
chromatic, I think, in that big prove argument, pointed out that Test::More
side-stepped the whole shove all functionality into one interface problem by
creating Test::Builder. TAP::Parser and prove should go in the same direction.
Over and above simply being a way to build new test libraries,
Looking at the tickets for Test::More I see it's mostly down to wishlist items
and unimportant things.
http://rt.cpan.org/Public/Dist/Display.html?Name=Test-Simple
I can identify only two real important bugs, as far as I'm concerned. The
first has to do with overloading. cmp_ok() doesn't DTRT
Andy Armstrong wrote:
On 30 Nov 2007, at 01:32, Michael G Schwern wrote:
The absurdity of :: becomes more clear because you can apply the same
arguments to any switch of prove. Let's use ++ instead of '--color'
because
its syntactically clean and visually distinct. Or ;; for --merge
A. Pagaltzis wrote:
* Michael G Schwern [EMAIL PROTECTED] [2007-11-30 02:35]:
Let's use ++ instead of '--color' because its syntactically
clean and visually distinct. Or ;; for --merge.
Except there’s no good precedent for sentinel values whereas
there are clear precedents for switches
1001 - 1100 of 1466 matches
Mail list logo
