On Tuesday 30 January 2007 22:17, Joshua ben Jore wrote:
> Then you can't use ref() because that return all kinds of wrong values.
Someone ought to put that on temporary tattoos and hand them out at every YAPC
for the next five years.
-- c
On 1/30/07, David Golden <[EMAIL PROTECTED]> wrote:
On 1/30/07, Joshua ben Jore <[EMAIL PROTECTED]> wrote:
> Interestingly, this has caused me to wonder how well Test::Exception
> handles the corner cases where $@ is clobbered during the scope ending
> of eval{} and related. I've just filed a bug
On 1/30/07, Joshua ben Jore <[EMAIL PROTECTED]> wrote:
Interestingly, this has caused me to wonder how well Test::Exception
handles the corner cases where $@ is clobbered during the scope ending
of eval{} and related. I've just filed a bug against it at
http://rt.cpan.org/Ticket/Display.html?id=2
Nadim Khemir wrote:
> The bad guys:
>
> # Check that something died
> dies_ok { $foo->method1 } 'expecting to die';
>
> Am I the only one who got this to pass, to find out later that what cause the
> error had nothing to do with the message I displayed. Checking that something
> dies is _no
On Tuesday 30 January 2007 12:18, Nadim Khemir wrote:
> Any of the subroutines could croak. So my point is "is there any point in
> using lives_and" at certain places when it's not used in thousands of other
> places?
Sure -- when calling code that you know throws exceptions under certain
circum
On 1/30/07, Nadim Khemir <[EMAIL PROTECTED]> wrote:
I believe the example in Test::Exception is not as good as it could be.
# Check that something did not die
lives_ok { $foo->method2 } 'expecting to live';
Doesn't explain much about when to use it.
You'd use (lives|dies|throws)_ok when
On Tuesday 30 January 2007 19:09, A. Pagaltzis wrote:
> * Nadim Khemir <[EMAIL PROTECTED]> [2007-01-30 18:20]:
> > # Check that a test runs without an exception
> > lives_and { is $foo->method, 42 } 'method is 42';
> > Isn't this equivalent to is($foo->method, 42 , 'method is 42')?
> > The test
On 1/30/07, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
* Pete Krawczyk <[EMAIL PROTECTED]> [2007-01-30 19:00]:
> How about code that dies with an object? dies_ok lets you
> inspect the object in $@, whereas throws_ok only lets you see
> if it's part of a class. What if you want to see if $@ meets
>
Subject: Re: Bad test functions in Test::Exception
From: Nadim Khemir <[EMAIL PROTECTED]>
Date: Tue, 30 Jan 2007 20:48:55 +0100
}> And finally, what if I truly don't care why something dies, just that it
}> did? Why should I be penalized for writing *any* test?
}
}And how would what I suggest pen
# from Nadim Khemir
# on Tuesday 30 January 2007 09:17 am:
> # all Test::Exceptions subroutines are guaranteed to preserve the
> state # of $@ so you can do things like this after throws_ok and
> dies_ok like $@, 'what the stringified exception should look like';
>
>This wouldn't be needed if die
On Tuesday 30 January 2007 18:53, Pete Krawczyk wrote:
> snip
> No, you're not - but shunning all possible uses of dies_ok becasue you
> didn't write a test as complete as you could have isn't the fault of
> Test::Exception.
> How about code that dies with an object? dies_ok lets you inspect the
On Tuesday 30 January 2007 19:19, A. Pagaltzis wrote:
> * Pete Krawczyk <[EMAIL PROTECTED]> [2007-01-30 19:00]:
> > How about code that dies with an object? dies_ok lets you
> > inspect the object in $@, whereas throws_ok only lets you see
> > if it's part of a class. What if you want to see if $@
* Pete Krawczyk <[EMAIL PROTECTED]> [2007-01-30 19:00]:
> How about code that dies with an object? dies_ok lets you
> inspect the object in $@, whereas throws_ok only lets you see
> if it's part of a class. What if you want to see if $@ meets
> multiple criteria? There's plenty of valid cases where
* Nadim Khemir <[EMAIL PROTECTED]> [2007-01-30 18:20]:
> # Check that a test runs without an exception
> lives_and { is $foo->method, 42 } 'method is 42';
> Isn't this equivalent to is($foo->method, 42 , 'method is 42')?
> The test framework will catch the error if any. It's just
> weird to att
Subject: Bad test functions in Test::Exception
From: Nadim Khemir <[EMAIL PROTECTED]>
Date: Tue, 30 Jan 2007 18:17:38 +0100
}I like Test::Exception, it's a very fundamental test module with
}Text::NoWarning, Test::Deep and other goodies. Still, I believe some of the
}functions made available sho
I like Test::Exception, it's a very fundamental test module with
Text::NoWarning, Test::Deep and other goodies. Still, I believe some of the
functions made available should not be there at all.
The good guys :
# Check that the stringified exception matches given regex
throws_ok { $foo->me
A, slightly, better way to handle diagnostics?
http://search.cpan.org/~nkh/Carp-Diagnostics-0.02/
Cheers, Nadim.
Adam Kennedy wrote:
> I for one would rather it wasn't.
>
> Remembering that NOBODY ever passes Makefile.PL params manually, you
> need every build system capable of supporting those params, and ever
> CPAN client to be capable of passing them.
>
> An environment variable is a direct line from th
On 30 Jan 2007, at 11:34, Adam Kennedy wrote:
I for one would rather it wasn't.
Remembering that NOBODY ever passes Makefile.PL params manually,
you need every build system capable of supporting those params, and
ever CPAN client to be capable of passing them.
An environment variable is a
I for one would rather it wasn't.
Remembering that NOBODY ever passes Makefile.PL params manually, you
need every build system capable of supporting those params, and ever
CPAN client to be capable of passing them.
An environment variable is a direct line from the user/system to EUMM
for ONL
On 30 Jan 2007, at 02:24, Michael G Schwern wrote:
That's one way, though I'd rather it be a Makefile.PL argument. [1]
Yup, OK.
The way I was thinking was to make it easier for users to write
MY::test_harness() so they can plug in any testing system, not just
Test::Harness compatible ones.
21 matches
Mail list logo
