On Tue, Mar 06, 2001 at 03:27:33PM +0000, Piers Cawley wrote:
> Matthew Astley <[EMAIL PROTECTED]> writes:
> > On Tue, Mar 06, 2001 at 11:59:40AM +0000, Piers Cawley wrote:
> > > Matthew Astley <[EMAIL PROTECTED]> writes:
[sort block style subs]
OK, the CodeRef does the simple and flexible. People can build stuff
onto it .. that's all we need.
> > > > Is it too complicated to allow our coderef objects to implement a
> > > > "do_failif" method instead of the "do_assert" ?
> > >
> > > The problem I see with 'do_failif' and an associated 'failif'
> > > mechanism is that of deriving meaningful failure messages for
> > > arbitrary coderefs. Not that this would necessarily be a problem...
> >
> > You code can still die ... ahhh. I've been doing quite a lot of "eval
> > this code and make sure it dies with an error matching qr//"
> >
> > I suspect this, like Adam says, is a time to roll my own assertion
> > classes outside the T:U namespace.
>
> "I want this assertion to fail. If you don't fail, die." Um...
No, I wanted (to assert that) the class method fails with a specific
error.
Since it takes several lines of waffle and I've done it many times, it
should be wrapped up .. hence rolling my own assertion class outside
PerlUnit.
> > > > I think if we could generalise this nicely it would also solve the
> > > > negative regexps problem.
> > >
> > > Good point.
> > >
> > > sub T::U::Assertion::Regexp::do_failif {
> > > my $self = shift;
> > > my $target = shift;
> > > $target !~ /$$self/ or
> > > $self->fail("'$target' matched /$$self/ unexpectedly\n");
> > > }
> >
> > I think I was after
> >
> > sub T::U::Assertion::NRegexp::do_failif {
>
> So, you want to create a new kind of assertion class, with a different
> interface, and I'm supposed to know which method to call depending on
> what class the assertion is. And because both sorts of class are going
> to be built from a regular expression, there's no good way for the
> automagic object builder to work out which class to automagically
> build.
>
> Whereas, adding 'do_failif' to the interface of an Assertion with the
> assumption that it's equivalent to asserting that the 'assertion'
> returns false will work for any possible Assertion subclass.
>
> I think I know which I prefer.
No, I meant something else at the time but I don't remember exactly
what. It's not important...
> > Problem is, a Regexp seems to be a blessed thingie already, but I
> > find any module file or comprehensive docs. Not that I looked _very_
> > hard.
>
> There isn't one. But see Test::Unit::Assertion::Regexp for a way of
> using it as the basis of an object.
Very nice. One minor detail from your pod though,
> Note that if you need to do a 'string does I<not> match this
> pattern' type of assertion then you can do:
>
> $self->assert(qr/(?!some_pattern)/, $some_string)
>
> ie. Make use of the negative lookahead assertion.
but
"spong" =~ qr/(?!ong)/ == 1
because it matches at some other place than where you told it not to.
Still, the problem goes away as soon as we pick a name.
> > > 'failif' or 'nassert'?
> >
> > or 'tressa'? Or is that too FORTRAN? (FORTRAN? I first bumped into
> > that with shell script...)
>
> I really don't like tressa. And having looked at '$self->failif' and
> '$self->nassert' when I was writing up those two code examples, I
> think I prefer nassert. But I don't really like that either.
> Suggestions welcome..
That's about as far as I got. tressa is pretty grim...
OK, let's not got to www.roget.com. Let's go to a word list and find
deny contradict refuse
The more words I see, the more concise failif sounds. Besides, Demon's
routing is up the spout again so I can't waste any more time following
the links.
Matthew #8-)
_______________________________________________
Perlunit-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/perlunit-devel
