-
Notifications
You must be signed in to change notification settings - Fork 2.5k
Description
The TestSuite
structures we use on the execution and result sides (robot.running.model
and robot.result.model
, respectively, with a common base classes in robot.model
) have certain things that need to be changed:
-
Remove
keywords
andmessages
from execution sideKeyword
objects. These keywords never actually have child keywords or messages, they just represent the keyword call with the keyword name and arguments. Basically this means moving the related code from the common base class to the result side model objects. -
TestSuite
objects should not havekeywords
attribute but instead should havesetup
andteardown
directly. Suites having keywords is odd in general and being able to use e.g.suite.setup
instead ofsuite.keywords.setup
is convenient. -
keywords
attribute used byTestCase
,For
,If
(new in RF 4.0) andUserKeyword
objects should be renamed tobody
. The body can contain FOR loops and soon also IF/ELSE in addition to keywords sobody
is a much better name thankeywords
and that's also the term parsing side model uses. The forthcomingIfElse
objects should naturally havebody
, notkeywords
, as well. -
Add
setup
andteadown
directly toTestCase
andUserKeyword
objects. Accessingtest.setup
is more convenient than the currenttest.keywords.setup
andtest.body.setup
would be just wrong. -
Make
setup
andteardown
objects, notNone
, also when they are not defined. This makes it easier for external code like pre-run modifiers to modify them. Their initial truth value should be false to make it possible to use code likeif test.setup:
.
This kind of changes are naturally backwards incompatible but in my opinion better model is worth that. We should, however, preserve keywords
as a deprecated read-only property that is generated based on body
and setup/teardown
when accessed.
[Update on 2021-01-18] Everything discussed above has now been done, but doing these changes has uncovered other highly related problems in the model that also need to be changed:
-
On the execution side make
For
andIf
independent classes instead of extendingKeyword
. They don't need keyword related attributes likename
orargs
, but instead they should have context specific attributes likeFor.flavor
andIf.condition
. Earlier those context specific attributes were implemented as properties but they should be normal attributes. Old keyword specific attributes should probably be preserved as deprecated properties for backwards compatibility. -
Add separate
visit/start/end_for
andvisit/start/end_if
methods to the visitor interface. EarlierFor
andIf
were visited usingvisit/start/end_keyword
but that doesn't work anymore when they don't extendKeyword
. -
Add separate
For
andIf
classes on result side. Currently FOR and IF construct are reported as keywords withtype
set accordingly. This makes inspecting FOR/IF hard because their context specific information is not directly available and need to be parsed from keyword attributes. For example, all FOR information is in keyword name in format like${x} IN [ a | b | c ]
. This change requires some changes to output.xml as well and I added a separate comment about that. -
On the result side move keywords' messages to
body
to preserve their relative order with keywords and FOR/IF constructs. This makes it easier to preserve their order also in log (Relative order of messages and keywords is not preserved in log #2086). The oldmessages
attribute should be preserved as a property to make accessing only messages easy.