On Wed, 2010-07-14 at 13:22 +0200, Josef Skladanka wrote:
Well, I understand what you're saying, but it has one tiny little
problem - you need to get the "self" reference in there. This is not a
big deal, really because you actually have the "self" as a first
parameter *args. But then we would need to decide, that the
"on_exception" method always has to be method of the respective class in
which the decorator was used (i'm not sure if it's clear, so lets shoot
some examples :)
Ahhh, okay. I read your examples (and played around a while) and I
finally understand how this works. Thanks for being patient with me!
Heh.
There's really no way we can define the handler to tell it to use the
instance method, since the object instance doesn't exist - there's no
'self.run_once_failed' until there's a 'self', and there's no
'self'
when you're defining the class.
So now that I understand the advantage of using a class and overriding
__call__(), I think that's a fine (and actually really clever) way to
handle this - so after my one last question below I think we'll be ready
to merge this into master.
> Would something like that work, or would that mess up
autotest's
> introspection?
Well, the introspection is broken once you use **kwargs somewhere in the
decorator (and decorators can not function without it), so the 'last arg
of the function has to be **kwargs when we decorate inside our tests'
still applies.
Interesting. Good to know.
So my last question is this: Should we rename (or subclass) BaseTest to
AutoQATest, or something like that? If plan to start adding
AutoQA-specific stuff to the class (automatic resultdb reporting, for
instance) I think it might be smart to change the name, to keep the
division between our autoqa extensions and the upstream autotest stuff
kind of clear. (Or at least no more muddy than it already is.)
And if we're going to change the class name, we should probably do that
before the merge. But maybe I'm just being nitpicky and we don't need to
worry about this. What do you think?
-w