Robot Framework part 1: Source Reader

[haxtibal]

This adds language aware reading of test cases from *.robot files. Each Robot Framework test case is represented as Function object in the internal StrictDoc model.

We gain following features compared to language agnostic text reading:

• sdoc can now have forward relations to specific test cases by test case name.
• Relation markers with scope=function will automatically cover the range from test case start line to test case end line, and are linked with the function object.
• An upcoming test result (output.xml) reader can automatically link test results with the related robot framework test cases.

For parsing we use the public parsing API provided by the upstream project. Thus "robotframework" becomes a dependency of strictdoc.

Note: Language aware reading is turned on by SOURCE_FILE_LANGUAGE_PARSERS in strictdoc.toml.

[stanislaw]

I cannot check your branch to run your tests locally today but it looks great overall.

I left only 2 minor comments.

[stanislaw]

Checked the itests quickly. Everything looks great. Thanks for contributing strongly.

[haxtibal]

I wonder if we should automatically add a role to the new test case function relations. I see similar already happens for test reports, where strictdoc automatically adds role "IsSatisfiedBy/Satisfies".

@stanislaw @nicpappler How about this:

• Auto assign roles for links to test case source code. Auto assigned roles shall be named hasTestCase. Rationale: That's what's currently in SPDX 3. I'd really like if we followed a standard vocabulary, and SPDX is probably the best bet (given the meaning behind SPDX:hasTestCase actually matches our use case).
• If user opted to define the role explicitly, as for example in @relation(scope=function, role=foo), don't auto assign, but use the user supplied value.

[stanislaw]

I wonder if we should automatically add a role to the new test case function relations. I see similar already happens for test reports, where strictdoc automatically adds role "IsSatisfiedBy/Satisfies".

This was a quick coding placeholder. Feel free to change it to a more matching name.

[stanislaw]

hasTestCase sounds reasonable.

[stanislaw]

hasTestCase sounds reasonable.

What is then the reverse name for this relation?

[haxtibal]

hasTestCase sounds reasonable.

What is then the reverse name for this relation?

That could best be answered by @nicpappler. If I understand correctly, there is no reverse name. SPDX assumes a from-end and a to-end, and clarifies the reverse by documentation:

Every to Element is a test case for the from Element

[haxtibal]

[...] test reports, where strictdoc automatically adds role "IsSatisfiedBy/Satisfies".

This was a quick coding placeholder. Feel free to change it to a more matching name.

No better idea at the moment. I merely mentioned it to ask "if we do auto-assignment already in test report parsing, should we do it also in source code parsing?".

[stanislaw]

hasTestCase sounds reasonable.

What is then the reverse name for this relation?

That could best be answered by @nicpappler. If I understand correctly, there is no reverse name. SPDX assumes a from-end and a to-end, and clarifies the reverse by documentation:

Every to Element is a test case for the from Element

We never discussed this in detail until now.

One way of doing this would be to do hasTestCase and maybe testCaseFor (writing this I am not sure I am onboard with the camelCase but that is a separate topic).

Another approach could just be saying TestCase and have both the forward and backward relations be named the same. I think @haxtibal you did something similar in your itests for markers/roles.

It is a great discussion point overall when it comes to synchronizing between what the SDoc does with its Parent/Child relations (forward and backward links) and what the SPDX does (I am not fully in the picture).

@haxtibal At the same time, your implementation should not be blocked by this naming issue, so you could proceed without changing this aspect just yet.

[nicpappler]

We currently do not have a SPDX relationship for a reverse trace from test to source or requirements yet. Also did not discuss it. The one that comes closest at the moment is hasInput. Please feel free to suggest a link/relationship name, I can take this to the SPDX meeting to get it into the SPDX version 3.1.