RoboCon 2022

One of the more challenging aspects to the adoption of Robot in an organization is the disconnect between high-level scenarios (Given... When... Then...) and the more statement-oriented Robot test syntax in which we started developing our tests. Using Robot's support for BDD-style syntactic sugar and ability to embed keyword arguments into the keyword name, we were able to transition to testcases which directly used high-level scenario descriptions, but at the cost of somewhat tortuous and lengthy keywords to provide all of the context for these keywords.

Then we developed the idea of "implicit context". This allows us to keep defining our scenarios in high-level BDD language:

When an anonymous user requests a new authentication token
Then that token request will be denied
And that token request response will include a message referencing the missing credentials

And simply have our keywords (and Robot) keep track of the implied context of these keywords using test variables:

${that_token_request}
${that_token_request_response}

To create a test language which more directly mirrors and leverages the power of written language, by being able to refer to 'previous' and 'first' and 'that' objects and actions by reference.

As these keywords are built up, documentation and maintenance become an issue. Which variables exactly are being read and written? How do I find a keyword which does what I want? And cut-and-paste boilerplate can proliferate. Our approach uses keyword tags (in:that_request, out:that_response, etc.) along with helper keywords to read and maintain a test's implicit context from beginning to end.

Let's get excited about using the power of natural language to think about and write our test scenarios!