This is partially true, but this is the beginning of a slippery slope
down to:
$i++ # increment $i by one
Things like can_ok($foo, "bar") are obvious on the surface -- but it's
good practice to document why you care that $foo can "bar", right?
Regards,
Jonathan Rockway
(My mind idly wonders
On 7/19/06, Gabor Szabo <[EMAIL PROTECTED]> wrote:
> Its not Test::More's job to enforce style. The more things are
> optional the more useful to more people it is.
What about someone creating a module Test::HaveNames or similar that
if added to a test file will add a last test being ok only i
On 7/19/06, Michael G Schwern <[EMAIL PROTECTED]> wrote:
Descriptions are optional because they are not necessary for the test.
Sometimes a test doesn't need a description, its obvious from reading
the code what its doing. Sometimes it would be redundant. Sometimes
you're just writing fast. I
chromatic wrote:
(My mind idly wonders if it were possible to generate this test description...
somehow... somewhere)
That's what I do with my Test:: modules. The test description is
optional, and if not provided the module generates a (hopefully)
sensible default.
N
* Michael G Schwern <[EMAIL PROTECTED]> [2006-07-19 02:10]:
> On 7/17/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
> >Had they been named parameters, we wouldn't be having this
> >discussion.
>
>is got => 'foo', expected => 'bar', description => 'foo is bar';
>
>is 'foo', 'bar', 'foo is ba
On Tuesday 18 July 2006 17:28, Jonathan Rockway wrote:
> If you really don't want to have test names, you can specify undef. But
> making them "required" (as in "before everything else") makes the API
> easier to use for people who are doing things right (i.e. naming their
> tests).
That's beggi
> I'd like test names to be more widespread, but I really don't want
> them mandatory.
If you really don't want to have test names, you can specify undef. But
making them "required" (as in "before everything else") makes the API
easier to use for people who are doing things right (i.e. naming th
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.
D
On 19/07/06, Michael G Schwern <[EMAIL PROTECTED]> wrote:
On 7/17/06, demerphq <[EMAIL PROTECTED]> wrote:
> IMO the best way to do that is to make test names mandatory.
The file and line number provided by the failing test isn't enough to find it?
Not always, but even so, mandatory test names i
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 tha
On 17 Jul 2006, at 12:49, Ovid wrote:
- Original Message
From: A. Pagaltzis <[EMAIL PROTECTED]>
[snip]
And you know what? We don’t even need Test::More::NextGen to
implement that. All functions as they stand could unambiguously
accept a hashref as their single argument.
That's goin
- Original Message
From: A. Pagaltzis <[EMAIL PROTECTED]>
> 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. Conclusion?
>
> Had they been named parameters, we wouldn’t be having this
> discuss
On 7/17/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
Hi all,
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.
Just to clarify, my main point is really that test names should be
mandatory. The fact that m
Hi all,
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. Conclusion?
Had they been named parameters, we wouldn’t be having this
discussion.
And you know what? We don’t even need Test::More::NextGen to
imp
14 matches
Mail list logo
