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
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
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
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 the
A, slightly, better way to handle diagnostics?
http://search.cpan.org/~nkh/Carp-Diagnostics-0.02/
Cheers, Nadim.
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 {
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
* 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 attempt to
* 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
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 $@ meets
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
# 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 dies_ok
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
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
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 framework
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 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
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 _not_ good
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
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
20 matches
Mail list logo
