Skip to content

Refactor execution and result side model objects #3749

@pekkaklarck

Description

@pekkaklarck

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 and messages from execution side Keyword 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 have keywords attribute but instead should have setup and teardown directly. Suites having keywords is odd in general and being able to use e.g. suite.setup instead of suite.keywords.setup is convenient.

  • keywords attribute used by TestCase, For, If (new in RF 4.0) and UserKeyword objects should be renamed to body. The body can contain FOR loops and soon also IF/ELSE in addition to keywords so body is a much better name than keywords and that's also the term parsing side model uses. The forthcoming IfElse objects should naturally have body, not keywords, as well.

  • Add setup and teadown directly to TestCase and UserKeyword objects. Accessing test.setup is more convenient than the current test.keywords.setup and test.body.setup would be just wrong.

  • Make setup and teardown objects, not None, 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 like if 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 and If independent classes instead of extending Keyword. They don't need keyword related attributes like name or args, but instead they should have context specific attributes like For.flavor and If.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 and visit/start/end_if methods to the visitor interface. Earlier For and If were visited using visit/start/end_keyword but that doesn't work anymore when they don't extend Keyword.

  • Add separate For and If classes on result side. Currently FOR and IF construct are reported as keywords with type 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 old messages attribute should be preserved as a property to make accessing only messages easy.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions