Comment #14 on issue 1208 by pekka.klarck: allow listeners to receive
suite, test case and keyword objects as arguments
http://code.google.com/p/robotframework/issues/detail?id=1208
I agree that the current objects are complex and hard to understand, but
one of the main targets of RF 2.8 will be making them much better. We have
already replaced objects used for presenting test results internally with a
new model that has a _really_ nice API:
from robot.model import TestCase
tc = TestCase(name='Example', tags=['t1', 't2'])
print tc.name, tc.tags
Example [t1, t2]
kw = tc.keywords.create(name='Example Keyword', args=['a1', 'a2'])
list(tc.keywords)
[<robot.model.keyword.Keyword object at 0xb77c3844>]
tc.keywords[0] is kw
True
print kw.name, kw.args
Example Keyword ['a1', 'a2']
print [a for a in dir(tc) if a[0] != '_']
['critical', 'doc', 'id', 'keyword_class', 'keywords', 'longname', 'name',
'parent', 'tags', 'timeout', 'visit']
print [a for a in dir(kw) if a[0] != '_' and not a.isupper()]
['args', 'doc', 'id', 'keywords', 'message_class', 'messages', 'name',
'parent', 'timeout', 'type', 'visit']
For more information about the new model see
http://robot-framework.readthedocs.org/en/2.7.4/autodoc/robot.model.html.
As noted on the docs, the plan is to use the same model with robot.running
package in RF 2.8 and I definitely don't want any extra layer on top of it.
I can see, for example, interesting use cases for being able to create
tests or keywords dynamically (see `tc.keywords.create` above).
Implementing proxies that support all the same functionality as the new
model would be both a big task and provide no real benefits over using
those objects directly.
The real problem for users of this new listener API is that the API
provided by these objects is going to change so much. If we are afraid of
that, the easy solution is adding the new listener API only in RF 2.8 when
the API provided by the objects is both better and stable. That actually
was the comment other Robot core devs had when I discussed this with them.
I would be willing to add the listener API already now, though, and just
document that the objects are going to change. Users could then create
their own compatibility layer on top of them if needed.
