* Nik Clayton <[EMAIL PROTECTED]> [2007-01-24 16:45]:
> Anyone used this approach before, or done anything similar?
I haven’t, but it seems perfectly reasonable if you can live with
Fatal’s annoying stack traces.
Another option would be something like
sub ensure { $_[ 0 ] or die "broken prom
On 1/24/07, Nik Clayton <[EMAIL PROTECTED]> wrote:
Has anyone ever used Test::More and Fatal together?
I have a test script, where each test builds upon the work of the previous
step (it's part of the Subversion Perl bindings test suite, and it checks
out files, makes changes to th
On Jan 24, 2007, at 1:25 PM, Nik Clayton wrote:
Chris Dolan wrote:
I don't like that very much. The implicit die() on test functions
will probably confuse subsequent readers of the code.
# Cause the listed functions to die on error
use Fatal qw(...);
Furthermore, I cannot believe th
Chris Dolan wrote:
I don't like that very much. The implicit die() on test functions will
probably confuse subsequent readers of the code.
# Cause the listed functions to die on error
use Fatal qw(...);
Furthermore, I cannot believe that ALL of your tests are critical.
150 or so out
On Jan 24, 2007, at 9:42 AM, Nik Clayton wrote:
Has anyone ever used Test::More and Fatal together?
I have a test script, where each test builds upon the work of the
previous step (it's part of the Subversion Perl bindings test
suite, and it checks out files, makes changes to them, co
Has anyone ever used Test::More and Fatal together?
I have a test script, where each test builds upon the work of the previous
step (it's part of the Subversion Perl bindings test suite, and it checks
out files, makes changes to them, commits them, and so on).
If any of these tests fa
