Adam Spiers <[EMAIL PROTECTED]> writes:
> Piers Cawley ([EMAIL PROTECTED]) wrote:
> > perl -MCPAN -e "install 'B::Deparse'", which isn't guaranteed to work
> > for older perls I'm afraid.
>
> It's already installed, just broken.
>
> > I thought I'd set PREREQ_PM to include B::Deparse,
>
> That also forces the user to have a working B::Deparse, so I'd much
> prefer your other suggestion:
>
> > but it shouldn't be too hard to code things so that you don't *have*
> > to have B::Deparse to get things working (fall back to file and
> > linenumber for example)
>
> That would be fine. Even returning
>
> "B::Deparse unavailable; can't display context"
>
> would be good enough for now.
>
> Any chance you could knock that up? I have several patches of my own
> which I'm struggling with to get into a commitable form.
I'll get on it.
>
> > > Secondly, how would an assertion using
> > >
> > > > $str_match = sub { $_[0] eq $_[1] or die "Expected $_[0], got $_[1]\n" }
> > > > $numeric = sub { $_[0] == $_[1] or die "Expected $_[0], got $_[1]\n" }
> > >
> > > distinguish between an exception raised within a test_method
> > > (e.g. die() if loading of fixture failed) and a failure?
> >
> > sub Test::Unit::Assertion::CodeRef::do_assert {
> > my $self = shift;
> > my $possible_object = shift;
> > $possible_object->$$self(@_) ||
> > $self->fail("$possible_object\->{$self}(" .
> > join (", ", @_) .
> > ") failed" . ($@ ? "with error $@." : "."));
> > }
> >
> > If the code dies, then its $@ is caught and appended to the message
> > passed into the 'fail' method. If you get a die during fixture
> > generation then it wouldn't get caught in this fashion.
>
> Even if fixture generation takes place within the same test_method as
> the assertion?
Err... What are you talking about?
If you mean
$self->assert(sub {#generate_fixture;
test_something || die "message"
}, ...)
Then, yes, it's going to be hard to distinguish between the fixture
failure and the assert failure, but if you mean:
sub test_foo {
make_fixture; # Could die
$self->assert(\&coderef, ...);
}
Then, I would assume that you're going to get either $@ that isn't an
object, or it'll generate an ExceptionError exception to throw, which
will be distinct from the ExceptionFailure thrown by the assert.
I could be barking up the wrong tree here, but I confess I fail to see
what you're driving at. Example code please?
> > > - T::U::Assertion and T::U::Assert both seem to be missing a
> > >
> > > use Test::Unit::ExceptionFailure
> >
> > Make that
> >
> > require Test::Unit::ExceptionFailure
> >
> > and I'll agree with you. You shouldn't really go around 'use'ing
> > class files unless you know they have an import method that you want
> > to make use of..
>
> Why not?
Style. Say what you mean and all that. If you mean 'I want to run the
import method' then use 'use'. If you mean 'I want to be sure that a
class file has been loaded' then use 'require';
> We've done that everywhere else in the code,
You've been doing it wrong everywhere else in the code then.
> and what type of class file would want to export stuff anyway?
A stupid one.
> If we're really concerned about not importing anything, we can
> always use the
>
> use Foo ();
>
> form.
That still means that 'import' could get run. Which is definitely not
doing the Right thing.
>
> > > line, and they duplicate the fail() method. Do we need both
> > > classes?
> >
> > Well, I'm not entirely sure what Test::Unit::Assert is doing there.
> > AFAICT it doesn't really do anything. Not sure what effect getting rid
> > of it, or rolling some of its functionality into Test::Unit::Test
> > would have though.
>
> T::U::Assert is only used by T::U::Test, where it inherits from it.
> Hmm. I can't see an obvious way of removing that duplication :-(
Heh. Christian? Any idea what T:U:Assert is doing there? Or is it a
holdover from JUnit?
--
Piers
_______________________________________________
Perlunit-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/perlunit-devel
