On Tue, Jun 30, 2009 at 2:46 PM, David Golden wrote:
> On Tue, Jun 30, 2009 at 2:15 PM, 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
On Tue, Jun 30, 2009 at 2:15 PM, 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?
Well, if you're doing inte
Ovid wrote:
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 better be true';
false 3, reason '3 had better still better be
I forgot to hit 'reply all' :)
Also, I had considered this:
have $some_value, assuming { shift > 7 }, reason "Argument must be greater
than 7";
And that would allow us to naturally put complex constraints onto the values.
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catal
- Original Message
> From: David Golden
>
> On Tue, Jun 30, 2009 at 1:17 PM, Ovidwrote:
> > Thoughts? Am I totally smoking crack here? If there's a clean way to
> shoehorn diagnostics on the Test::More-style interface, I guess that would be
> ok.
>
> Doesn't Test::Builder2 address
On Tue, Jun 30, 2009 at 6:17 PM, Ovid wrote:
>
> Part of the problem with have with 'Test::More' and friends is that there's
> not an easy way to attach diagnostics to any test. This is largely because
> the interface is set in stone. So I was thinking about a rewritten test
> interface which
On Tue, Jun 30, 2009 at 1:17 PM, Ovid wrote:
> Thoughts? Am I totally smoking crack here? If there's a clean way to
> shoehorn diagnostics on the Test::More-style interface, I guess that would be
> ok.
Doesn't Test::Builder2 address this? I'd rather see more energy
directed at getting that do
Part of the problem with have with 'Test::More' and friends is that there's not
an easy way to attach diagnostics to any test. This is largely because the
interface is set in stone. So I was thinking about a rewritten test interface
which allows something like this (this code actually works,
On Jun 30, 2009, at 12:13 AM, Ovid wrote:
And that would potentially have issues when it assigns "\t" to $name
and -12 to $age, even those are both valid values for the types in
question. It would be very difficult to find data which
automatically fits any random type, but it could be writ
- Original Message
> From: Ricardo SIGNES
>
> I updated my Test:: libraries to Test::Builder->new in their test routines,
> instead, as that's what I thought the original wisdom was. Is that still
> okay? (I did not add subtest-specific tests.)
>
> That is, I turned:
>
> my $TEST
On Tue, Jun 30, 2009 at 11:01 AM, David Golden wrote:
> On Tue, Jun 30, 2009 at 10:21 AM, Ovid wrote:
>> my $BUILDER = Test::Builder->new;
>
> I'm running visitcpan to generate a list of offenders now. Results posted
> soon.
And here we go: http://echo.dagolden.com/~xdg/2009-06-30-test-builde
On Tue, Jun 30, 2009 at 10:21 AM, Ovid wrote:
> my $BUILDER = Test::Builder->new;
I'm running visitcpan to generate a list of offenders now. Results posted soon.
-- David
* 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:
I updated my Test:: librar
>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
Test::Builder. Previously you could do stuff like this:
package Test::
(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 Test::Builder. Previo
Ovid wrote:
> use Test::Sims::Moose 'random';
>
> Person->new(
> name => random('Person.name'),
> age => random('Person.age')
> );
>
> And that would potentially have issues when it assigns "\t" to $name and -12
> to $age
> , even those are both valid values for t
On 29 Jun 2009, at 21:21, Gabor Szabo wrote:
When running tests with prove -a file.tar.gz it nicely creates the
archive file
but if the test bails out the archive file is not created at all.
Is this a feature or a bug ?
Bug I'd say...
--
Andy Armstrong, Hexten
- Original Message
> From: Michael G Schwern
>
> Ovid wrote:
> > First feature request: automatic Moose support to build random data which
> > conforms to Moose constraints :) (Yes, I know it's much, much harder than
> it sounds).
>
> Hello, what?
package Person;
use Moose;
h
18 matches
Mail list logo
