- Original Message
> From: Michael Peters
>
> > use Test::Fluent 'no_plan';
> >
> > my ( $have, $want ) = ( 1, 1 );
> > have $have, want $want, reason 'Some test name';
> > have [ 3, 4 ], want [ 4, 5 ], reason 'cuz I said so'; # fails
> > true 3, reason '3 had be
2009/7/2 Paul Fenwick :
> Since the line in question is using diag(), it already does have a #
> prepended to it. AFAIK most TAP parses pass that through to the user by
> default.
diag() writes to STDERR by default, so it's noisy and clutters output. Core
tests use C instead for this reason.
Is
On Monday 29 June 2009 23:03:00 Thomas Klausner wrote:
> Hi!
>
> See over there: http://use.perl.org/~domm/journal/39189
Hi Thomas!
Is this the reason that CPANTS was out-of-date for a long time? It seemed
better yesterday, though.
Regards,
Shlomi Fish
--
On Jul 2, 2009, at 3:32 AM, Rafael Garcia-Suarez wrote:
2009/7/2 Paul Fenwick :
Since the line in question is using diag(), it already does have a #
prepended to it. AFAIK most TAP parses pass that through to the
user by
default.
diag() writes to STDERR by default, so it's noisy and clutt
* David Golden [2009-06-30T14:46:47]
> Well, if you're doing interface design, one of the first things that
> comes to mind is that the name of the test should come first, not
> last.
...I basically liked everything you had to say here:
> test "label goes here" => is( $have, $want ) => diag
Ovid wrote:
> (Helps if I send this from a subscribed address):
>
> From http://use.perl.org/~Ovid/journal/39193
>
> The latest developer release of Test::More allows subtests. Subtests are great
> in that they solve a lot of problems in advanced Perl testing, but they have
> required a change in
Ricardo SIGNES wrote:
> * Ovid [2009-06-30T10:21:24]
>> The latest developer release of Test::More allows subtests. Subtests are
>> great in that they solve a lot of problems in advanced Perl testing, but they
>> have required a change in Test::Builder. Previously you could do stuff like
>> this:
Ovid wrote:
> Also, I think playing around with more fluent interfaces is a good idea.
> If my interface is great, why not? If it's bad, what would people *love*
> to see in a test interface which allows them to naturally write tests?
FWIW I don't see anything about either Ovid's or David's ideas
This is a quick release to sync with perl so 5.10.1 can release with a stable
version number. It does NOT include the subtest() code in 0.89_01 (don't
worry, it'll be back).
http://github.com/schwern/test-more/tree/v0.90
0.90 Thu Jul 2 13:18:25 PDT 2009
Docs
* Finally added a note abo
Craig A. Berry wrote:
> On Thu, Jul 2, 2009 at 4:03 PM, Michael G Schwern wrote:
>> This is a quick release to sync with perl so 5.10.1 can release with a stable
>> version number. It does NOT include the subtest() code in 0.89_01 (don't
>> worry, it'll be back).
>
> The attached patch does two t
# from Ovid
# on Tuesday 30 June 2009 10:17:
>So I was thinking about a rewritten test interface which allows
> something like this (this code actually works, by the way):
I only skimmed the thread, but it doesn't look like anyone mentioned
TestML.
http://testml.org/
Yes, there's a lot to be
11 matches
Mail list logo
