On Wed, May 16, 2001 at 10:05:37AM -0700, Andrew Maltsev wrote:
>Matthew wrote:
>>Christian wrote:
> > > Not my favorite approach. I am inclined to go in Andrews
> > > direction. Does Andrew's approach break anything? I don't think
> > > so. In all of his three cases, our "if ($exception)" still has
> > > the same truth value. Any counterexamples I am missing?
> >
> > Only example I can think of it where a user's test does
> > eval{testcode}. I haven't actually done this in any of mine, at
> > least
>
> Can't think of a problem with it, why is it a counterexample? On return
> from your outer eval {} $@ would be reset.
Oh, I meant that your fix only fixes the perlunit code; it still
allows the user to fail to detect a test that failed in an eval.
The nearest example I can think of is the use of closures in test
routines[1]. For a task that's repeated on several sets of data, I
normally make an anon sub which can assert on the lexically scoped
$self.
This works fine until I decide to run this closure in an eval, which
AFAICR I've not done - it would be nasty and not very clever, but
somebody's bound to do it...
We could provide a package method for testing the $@ from the eval,
but that's a bit heavy.
Matthew #8-)
--
[1] This is probably telling me that I should split that test off into
a separate suite, with common setup and some nice clean separation
of the different sub-cases. Problem is, I'd be completely swamped in
small files if I did that. At the moment I prefer to keep the tests
with the code they're testing...
_______________________________________________
Perlunit-users mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/perlunit-users
