On Thursday 29 November 2007 19:21:12 Andy Armstrong wrote:
> I don't believe producer (Test::Builder) and consumer (Test::Harness)
> are necessarily entirely alike or symmetrical in this regard. T::B
> pushes and T::H pulls - which makes callbacks or some higher level
> event driven interfa
On Nov 29, 2007, at 04:20, Andy Armstrong wrote:
[X] --
[ ] something else (please specify)
Best,
David
On Nov 29, 2007, at 03:34, Ovid wrote:
Could we not add a feature to prove and/or runtests such that, any
arguments after a bare "--" will be passed on to the scripts it
runs?
I've often wanted this myself, and --exec seems like overkill to
me.
Seconded.
Just to clarify, --exec *is* overk
# from Michael G Schwern
# on Thursday 29 November 2007 19:00:
>Otherwise, what's important to people?
Could it be made fork-safe?
http://search.cpan.org/src/TJENNESS/File-Temp-0.19/t/fork.t
Possibly that involves blocking, or IPC with delayed output, or a
plan-per-fork thing.
--Eric
--
".
On 30 Nov 2007, at 03:00, Michael G Schwern wrote:
Otherwise, what's important to people? I know there's a lot of
suggestions
about increasing the flexibility of planning. Also the oft
requested "I'm
done running tests" sentinel for a safer "no_plan". Most of the
time I'm just
wibbling ov
On 30 Nov 2007, at 02:51, Michael G Schwern wrote:
I think with TAP there's two central desires.
1) Want to add / change functionality in Test::Harness or prove. For
example, one that adds color, another that saves the TAP results,
another that
emails a report at the end of the test.
Pret
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 wi
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,
On 30 Nov 2007, at 02:07, Michael G Schwern wrote:
[snip perfectly reasonable argument]
Also, shell is a ubiquitous tool that you're going to use over and
over again,
so some rote learning is justified. prove is not such a thing.
You may well be right. We may all be right. I'm losing the wil
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 swi
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
* 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. find(1) uses `;` and
`+
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.
It's not a switch. It's the
On 30 Nov 2007, at 01:23, A. Pagaltzis wrote:
* Andy Armstrong <[EMAIL PROTECTED]> [2007-11-30 01:45]:
If you want to be able to flip flop in and out of test args and
prove args modes just repeat it and say that tests can't use
'::' as an arg.
$ prove -rb :: gargoyle :: --state=hot,save,all ::
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 30 Nov 2007, at 01:22, chromatic wrote:
I wonder if all of these different features for *running* tests
should go into
modules that play together nicely and compose in such a way that
writing our
own individual runner scripts is as easy as using Test::Builder is.
Well it kinda is. The s
I wonder if all of these different features for *running* tests
should go into
modules that play together nicely and compose in such a way that
writing our
own individual runner scripts is as easy as using Test::Builder is.
Agreed. We've got this brand new flexible parser doodad, and we'
* Eric Wilhelm <[EMAIL PROTECTED]> [2007-11-30 01:35]:
> This means buzzword#42 (simplethingssimple-hardthingspossible)
> where the complicated (aliases, wrappers, etc) case is like:
YAGNI.
We already have other ways to make hard things possible. “Hard
things possible” does not imply “using exact
On Thursday 29 November 2007 16:55:50 Andy Armstrong wrote:
> The state stuff is useful I think. Passing args to tests is more
> marginal and I certainly don't believe it's a big enough deal to
> warrant the amount of debate it's attracted.
I'm not disputing the utility. This all reminds me of f
On 30 Nov 2007, at 00:51, chromatic wrote:
$ prove -rb :: gargoyle :: --state=hot,save,all :: splendour :: t/
spog.t
Y'know, at some point I think I'll just write my own wrapper around
TAP::Harness, with attractive members of the appropriate gender, and
blackjack, and an amusement park.
That i
On Thursday 29 November 2007 16:43:18 Andy Armstrong wrote:
> $ prove -rb :: gargoyle :: --state=hot,save,all :: splendour :: t/spog.t
Y'know, at some point I think I'll just write my own wrapper around
TAP::Harness, with attractive members of the appropriate gender, and
blackjack, and an amuse
On 30 Nov 2007, at 00:34, Eric Wilhelm wrote:
It's not so-much 'technical limitations' as 'loss of clarity' wrt
spaces
that kills the quoted scheme.
I suggest that there be a start sentinel and optional end sentinell
--test-args --foo --bar --baz --whatever and -- such
Would call the tests
On 30 Nov 2007, at 00:25, Eric Wilhelm wrote:
Aha. I see; those were examples that hadn’t come up before. So
ordering is useful to avoid an explosion of options.
Or ... WE COULD HAVE AN ORDERING OPTION PARSER!
SPEAK UP.
We could, indeed, have an ordering option parser. But I suspect
ordere
# from Michael G Schwern
# on Thursday 29 November 2007 15:34:
>One of...
>
>--test_args='--foo --bar'
>
>or
>
>--start_test_args --foo --bar --end_test_args
>
>I prefer the former, but if technical limitations in the way we call
> the test programs force us to keep the arguments as a list...
It'
# from A. Pagaltzis
# on Thursday 29 November 2007 14:34:
>> failed,todo,all
>>
>> would do something sensible and distinct from
>>
>> todo,failed,all
>
>Aha. I see; those were examples that hadn’t come up before. So
>ordering is useful to avoid an explosion of options.
Or ... WE COULD HAVE AN
On 29 Nov 2007, at 23:36, Michael G Schwern wrote:
When does state get cleared?
When you save a new state over the top of it. In practice you don't
need to explicitly clear it I think. I could add an erase option - or
you could just rm .prove.
--
Andy Armstrong, Hexten
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 th
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 e
On 29 Nov 2007, at 22:38, Andy Armstrong wrote:
Fixed - although I have test failures on our smoke boxes at the
moment.
Fixed also.
--
Andy Armstrong, Hexten
On 29 Nov 2007, at 22:34, A. Pagaltzis wrote:
Aha. I see; those were examples that hadn’t come up before. So
ordering is useful to avoid an explosion of options. At the same
time, there is a bunch of aspects where order sensitivity clearly
does not make sense: does save,todo,failed do something u
* Andy Armstrong <[EMAIL PROTECTED]> [2007-11-29 23:25]:
> On 29 Nov 2007, at 22:09, A. Pagaltzis wrote:
>> Why this mental overhead? Do they really have to be ordered?
>> Is there any way that any other order would do anything
>> remotely useful? Would `save,fail,all` be useful? Or
>> `all,save,fa
On 29 Nov 2007, at 22:09, A. Pagaltzis wrote:
(option order matters, 'fail' adds the failed tests to the run
queue, 'all' adds everything, list is de-duped so the failures
run first, saved for next time)
Why this mental overhead? Do they really have to be ordered? Is
there any way that any othe
On 29 Nov 2007, at 22:10, Eric Wilhelm wrote:
How does an alias play-along with that? Can I say "--state=save" in
the
alias and --state=hot on the command-line?
You can as of r887 :)
--
Andy Armstrong, Hexten
* Andy Armstrong <[EMAIL PROTECTED]> [2007-11-29 16:10]:
> $ prove --state=fail,all,save
>
> ?
>
> (option order matters, 'fail' adds the failed tests to the run
> queue, 'all' adds everything, list is de-duped so the failures
> run first, saved for next time)
Why this mental overhead? Do they rea
# from Andy Armstrong
# on Thursday 29 November 2007 12:26:
>Eric: I *really* like have all the state selectors in a single switch.
> Please have a look at it and tell me if you find it awful.
How does an alias play-along with that? Can I say "--state=save" in the
alias and --state=hot on the
* Philippe Bruhat (BooK) <[EMAIL PROTECTED]> [2007-11-29 15:30]:
> Mmm, maybe I like ++ over ::. And -- should be kept meaning
> what it already means.
I think `++` is a legal filename on Windows, as opposed to `::`.
(But I haven’t a Windows box here to check, so if someone else
can confirm…)
Reg
On 29 Nov 2007, at 16:05, Adrian Howard wrote:
I like this coz my preferred way of working is to run all of the
tests all of the time, rather than just the particular test script
that I'm working on at the moment. That way if I have some dumb code
that breaks something else in the system I g
Salve J Nilsen <[EMAIL PROTECTED]> writes:
> Smylers said:
>>
>> The convention of using '--' to mean 'that's the end of my own
>> arguments' neatly avoids all of these issues.
>
> FWIW, I'm with Smylers here. '--' has been around for many years as a
> command-line convention for "signifying the e
On 29 Nov 2007, at 17:42, Eric Wilhelm wrote:
If the option parser preserved the order of the flags, you wouldn't
have
to cram that all into an '=foo,bar' opterand.
--save-state
--no-save-state
--failed-only
--failed-first
(Yes, needs more thought in the "abbreviation and short uniqueness
# from Andy Armstrong
# on Thursday 29 November 2007 09:08:
>On 29 Nov 2007, at 17:10, Eric Wilhelm wrote:
>>> # Run all tests
>>> $ prove --state=save -rb t/*.t
>>
>> I would rather just '--save-state', why do the "=foo,bar" thing ?
>
>Because it allows you to express what you'd like to have happ
On Nov 29, 2007, at 11:30 AM, Andy Armstrong wrote:
I really really really don't like the idea of basing it on a given
seed. I want to be able to know state about the tests that have
run, the order they were in, etc, without having to go through
prove to generate the sequence for me.
M
On 29 Nov 2007, at 17:28, Andy Lester wrote:
Good call. I'll do that too then.
I really really really don't like the idea of basing it on a given
seed. I want to be able to know state about the tests that have
run, the order they were in, etc, without having to go through prove
to genera
On Nov 29, 2007, at 10:22 AM, Andy Armstrong wrote:
prove --shuffle=$seed
Or perhaps App::Prove can cache the last random seed used and use
that
if someone wants to repeat the last shuffle:
prove --last-shuffle
Good call. I'll do that too then.
I really really really don't like the i
On 29 Nov 2007, at 17:10, Eric Wilhelm wrote:
# Run all tests
$ prove --state=save -rb t/*.t
I would rather just '--save-state', why do the "=foo,bar" thing ?
Because it allows you to express what you'd like to have happen with
the saved state.
--
Andy Armstrong, Hexten
On 29 Nov 2007, at 17:03, Eric Wilhelm wrote:
Why are we voting?
To solicit the opinions of interested parties.
--
Andy Armstrong, Hexten
# from Andy Armstrong
# on Thursday 29 November 2007 06:56:
># Run all tests
>$ prove --state=save -rb t/*.t
I would rather just '--save-state', why do the "=foo,bar" thing ?
Just always save? Then --only-failed will always work without needing
to re-run with the save flag? I guess an env var
# from Andy Armstrong
# on Thursday 29 November 2007 04:20:
>[ ] --
>[X] something else (please specify)
The -- means "end of options" for prove, which makes everything coming
after that into a filename. This usage replaces that meaning with
something entirely different and unexpected.
Why ar
On 29 Nov 2007, at 16:18, Ovid wrote:
Yup. I'm working on it now so I'll incorporate something like that.
Thanks :)
While you're at it, we can eliminate this bug (this is related to a
stateful prove):
http://rt.cpan.org/Public/Bug/Display.html?id=2101
Someone wants to be able to shuffle test
--- Andy Armstrong <[EMAIL PROTECTED]> wrote:
> Yup. I'm working on it now so I'll incorporate something like that.
> Thanks :)
While you're at it, we can eliminate this bug (this is related to a
stateful prove):
http://rt.cpan.org/Public/Bug/Display.html?id=2101
Someone wants to be able to
On 29 Nov 2007, at 16:05, Adrian Howard wrote:
I think that's subtly different from most-recently-failed order.
"-state=fail,all,save" gives me failing tests first. If I'm reading
you right it doesn't apply ordering within the groups of tests.
Running all tests in most-recently-failed order
On 29 Nov 2007, at 15:08, Andy Armstrong wrote:
[snip]
One I'd like even more would be to run tests in order of most-
recently-failed. It's something I've hacked together several times
at various companies with T::H::Straps.
$ prove --state=fail,all,save
?
(option order matters, 'fail' add
On Thu, Nov 29, 2007 at 12:20:49PM +, Andy Armstrong wrote:
>
> Let's have a quick show of hands and move on, eh?
>
> [ ] --
> [ ] something else (please specify)
>
> Press the red button to vote.
>
[X] ++
--
Philippe Bruhat (BooK)
The greatest monster of them all is ignorance.
On 29 Nov 2007, at 15:14, Paul Johnson wrote:
I think the chad is hanging.
I'm sure it'll be fine.
--
Andy Armstrong, Diebold
On Thu, Nov 29, 2007 at 02:57:34PM +, Andy Armstrong wrote:
> On 29 Nov 2007, at 14:54, Andy Lester wrote:
>> On Nov 29, 2007, at 6:20 AM, Andy Armstrong wrote:
>>
>>> [ ] --
>>> [ ] something else (please specify)
>>
>> --testargs='--foo --bar'
>
>
> You spoilt your ballot by not checking a bo
On 29 Nov 2007, at 15:08, Andy Armstrong wrote:
$ prove --state=fail,all,save
?
(option order matters, 'fail' adds the failed tests to the run
queue, 'all' adds everything, list is de-duped so the failures run
first, saved for next time)
And, of course,
$ prove --state=pass
to make sur
On 29 Nov 2007, at 15:04, Adrian Howard wrote:
On 29 Nov 2007, at 14:56, 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 thir
On 29 Nov 2007, at 14:56, 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 progr
On 29 Nov 2007, at 14:54, Andy Lester wrote:
On Nov 29, 2007, at 6:20 AM, Andy Armstrong wrote:
[ ] --
[ ] something else (please specify)
--testargs='--foo --bar'
You spoilt your ballot by not checking a box :)
(but I'll count it anyway)
--
Andy Armstrong, Hexten
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 previously - so as you fixed thin
On Nov 29, 2007, at 6:20 AM, Andy Armstrong wrote:
[ ] --
[ ] something else (please specify)
--testargs='--foo --bar'
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
On Thu, Nov 29, 2007 at 04:10:12AM +0100, A. Pagaltzis wrote:
> * Andy Armstrong <[EMAIL PROTECTED]> [2007-11-29 04:02]:
> > I agree re the semantics of '--' - but I'd rather have a
> > sentinel than a quoted string. Having to get nested quoting
> > right is a bit of cognitive load we can spare peo
[X] --
[ ] something else (please specify)
And don't forget the ponies.
On 29 Nov 2007, at 12:20, Andy Armstrong wrote:
[X] --
[ ] something else (please specify)
--
Andy Armstrong, Hexten
On 29 Nov 2007, at 12:20, Andy Armstrong wrote:
[X] --
[ ] something else (please specify)
Adrian
On 29 Nov 2007, at 10:34, Tom Heady wrote:
If we have just -- then its straightforward what to do with the
arguments. After everything up to and including -- has been
shifted off
@ARGV, then you can just do:
my @test_args = @ARGV;
and if $test_file is the test being run you can then do the m
--- chromatic <[EMAIL PROTECTED]> wrote:
> > Could we not add a feature to prove and/or runtests such that, any
> > arguments after a bare "--" will be passed on to the scripts it
runs?
> > I've often wanted this myself, and --exec seems like overkill to
me.
>
> Seconded.
Just to clarify, --exe
Smylers wrote:
Andy Lester writes:
As much as I like the non-quotedness of the -- or --testargs idea, I
really think it needs to be --testargs='--foo --bar'.
If we have just -- then its straightforward what to do with the
arguments. After everything up to and including -- has been shifted of
Smylers said:
The convention of using '--' to mean 'that's the end of my own
arguments' neatly avoids all of these issues.
FWIW, I'm with Smylers here. '--' has been around for many years as a
command-line convention for "signifying the end of options." (from
bash(1)).
/me likes gentle lea
On Thu, Nov 29, 2007 at 10:14:29AM +, Smylers wrote:
> Michael G Schwern writes:
>
> > There's nothing about '--' which indicates "pass the rest through to
> > the tests".
>
> It did to me, honestly! As soon as I opened David's e-mail at the start
> of this thread the "--" jumped out of the
Andy Lester writes:
> As much as I like the non-quotedness of the -- or --testargs idea, I
> really think it needs to be --testargs='--foo --bar'.
If we have just -- then its straightforward what to do with the
arguments. After everything up to and including -- has been shifted off
@ARGV, then y
Michael G Schwern writes:
> There's nothing about '--' which indicates "pass the rest through to
> the tests".
It did to me, honestly! As soon as I opened David's e-mail at the start
of this thread the "--" jumped out of the paragraph of text, and I
guessed what his words would say before I read
71 matches
Mail list logo
