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
>> p
As much as I like the non-quotedness of the -- or --testargs idea, I
really think it needs to be --testargs='--foo --bar'. I realize 3.04
is out there right now, but I think that it's not too late to change.
xoxo,
Andy
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdan
# 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
> programmaticly constructing prov
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 '--' -
On 29 Nov 2007, at 03:10, A. Pagaltzis wrote:
How about a double colon?
$ prove -v t/sprocket.t :: --teeth 12
It’s quite unlikely that anyone would name a test file `::`. In
fact no one who has to care about Windows at all (which would be
everyone who isn’t writing (Linux|Mac|BSD)::* modules
* 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 people from.
>
> So:
>
> * Andy's --testargs has the disadvantage of bein
On 29 Nov 2007, at 02:38, Andy Armstrong wrote:
How about some other short, not arg like, shell safe punctuation
sequence?
$ prove -v t/sprocket.t -+ --teeth 12
Actually I prefer
$ prove -v t/sprocket.t ++ --teeth 12
:)
--
Andy Armstrong, Hexten
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 have a sentinel than
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 '--'. Fo
On 29 Nov 2007, at 01:13, Paul Johnson wrote:
The only reasons I can think of are that either we have a more
important
use for passing through options or we think that we might have in the
future. Without breaking backwards compatibility, this is a unique
resource.
It is done :)
http://h
On Thu, Nov 29, 2007 at 12:47:39AM +, Andy Armstrong wrote:
> On 29 Nov 2007, at 00:27, Smylers wrote:
>>> Agreed. I think the '--' is redundant
>>
>> But is it doing harm? There are quite a few commands which use -- to
>> mean 'end of options; what follows is data' (where "data" can (and oft
On 29 Nov 2007, at 00:27, Smylers wrote:
Agreed. I think the '--' is redundant
But is it doing harm? There are quite a few commands which use -- to
mean 'end of options; what follows is data' (where "data" can (and
often
does mean) options to pass opaquely to another command being invoked).
Andy Armstrong writes:
> On 28 Nov 2007, at 21:06, Andy Lester wrote:
>
> > Which is why I said --testargs
> >
> > prove -v t/fetch.t --testargs http://wakeupandya.com/
>
> I thought --testargs was a metasyntactic name for a test argument :)
>
> Sorry folks. I'm being even more dense than u
Andy Armstrong writes:
> > > > 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.
>
> Agreed. I think the '--' is red
On 28 Nov 2007, at 21:13, Andy Armstrong wrote:
Sorry folks. I'm being even more dense than usual tonight. It's a
good idea and I'm +1 on implementing it once the dust settles on
what form it should take.
And while I'm at it I think
$ prove -
should read TAP from STDIN, right?
--
Andy Arm
On 28 Nov 2007, at 21:06, Andy Lester wrote:
would attempt to run a test called "http://example.com";. So you do
need some, ideally shell safe, marker that tells prove where to stop.
Which is why I said --testargs
prove -v t/fetch.t --testargs http://wakeupandya.com/
I thought --t
On Nov 28, 2007, at 3:02 PM, Andy Armstrong wrote:
prove -v t/fetch.t http://example.com
would attempt to run a test called "http://example.com";. So you do
need some, ideally shell safe, marker that tells prove where to stop.
Which is why I said --testargs
prove -v t/fetch.t --t
On Wednesday 28 November 2007 12:47:59 Andy Lester wrote:
> My only request would be that we not overload the meaning of --.
That ship has (GNU/getops) sailed.
-- c
On 28 Nov 2007, at 20:56, Andy Armstrong wrote:
I could easily see, though:
prove -v t/ --testargs --db=test
which would be less ambiguous than
prove -v t/ -- --db=test
Agreed. I think the '--' is redundant
Although, if we're talking about non-switches (sorry, I'm just
catching up with t
On 28 Nov 2007, at 20:47, Andy Lester wrote:
On Nov 28, 2007, at 2:44 PM, chromatic 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
On Nov 28, 2007, at 2:44 PM, chromatic 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.
My only request would be tha
On Wednesday 28 November 2007 12:23:16 David E. Wheeler 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.
-- c
On Nov 28, 2007, at 02:17, Ovid wrote:
I would like to be able to provide the tests run via 'prove' with
options something like this:
some_variant_of_prove t/*.t --option1 --option2 arg1 arg2
... where those 4 command-line options/arguments would be available
to
*each* of the individual tes
(For those those who missed the initial conversation, a deferred plan
is like 'no_plan' except the developer specifies the number of tests at
the end of the run instead of Test::Builder just listing how many tests
have run.)
Once again I find that deferred plans would be very helpful. I have a
te
--- James E Keenan <[EMAIL PROTECTED]> wrote:
> I know in advance that some of my users call myperlprogram.pl with
> options and some don't -- but I don't know what values they provide
> for
> those options. I would like my tests to be sufficiently flexible as
> to
> be able to handle the vario
25 matches
Mail list logo
