Keyword abstraction (robotframework)
Keyword abstraction (robotframework)

Keyword abstraction (robotframework)

A small piece of experience, comes from one email discussion, quite a long time passed, I haven’t organized it yet, so forgive its rough format…

People always say that they need to add a lot of comments to explain complex logic or plentiful parameters, they forgot to look at the "keyword abstraction" feature of Keyword Driven approach, which means we could have different layers of keywords, which has different numbers of parameters and different flexibility. For example, having the keyword "Dig" as below, and using descriptive variable names, to make its usage clear; then encapsulate it with fixed parameters to be higher level user keywords like "Dig A Hole", which fixed the target to be a hole.

In this way, we sliced the functionality, and avoided writing enormous documentations which is unnecessary and troublesome.

2. case table
   | Create ONE Default HSDPA Call For Traffic
   | Dig A Hole | ${on the ground} | ${a scoop}
   | Dig A Hole With A Scoop On The Ground |  // an
alternative for upper one, I prefer this style
   | Dig | ${place} | ${tool} | ${well}
=======> information above shows the "motivation
of the tests / user scenario of feature" and "how user
               amateur only need to care at this

3. keyword
   | Dig A Hole |
[Arguments] | ${place} | ${tool} |                |
   |                  |
Dig               | ${place} | ${tool} | ${a hole} |
4. library
   def dig(self, place,
tool, hole):

=======> information
above describes how we enable user’s moves.
              people who
maintains this need to know the details.
If you have
    | Dig | ${a} | ${b} |
${c} |
then you definitely need
to add many comments, e.g.

    | Dig | ${a} | ${b} |
${c} |    // ${a} for where you dig, ${b} for the tool used, ${c} for what you
want to dig for

but if you have keywords like
    | Dig | [Arguments] | ${place} | ${tool} |
${target} |
then you know how many parameters you need, and what do
they mean.

Another email discussion :

why not do it in this way :
1. "Collect Log After Test Executed"           //
Team A made. and I understand it’s for all units. the detail implementation of
this user keyword as below

       | ${all units}= | Get Units
       | ::FOR           | ${unit}     | IN | ${all units}
                          | Collect Log Of Unit | ${unit}

2. "Collect Logs Of All

       | ${all units}= | Get Units |
::FOR           | ${unit}     | IN | ${all units} |
                   | Collect
Log Of Unit | ${unit}

   "Collect Alarms Of All

       | ${all units}= | Get Units
       | ::FOR           | ${unit}     | IN | ${all units}
                          | Collect Alarms Of Unit | ${unit}

// team B made a new keyword. Let’s refactor

// if you put this keyword at the end of test case,
it means "after test executed" already, no need to repeat in the keyword
// better to explicitly mention it’s for "all
3. "Collect Logs And
Alarms After Test Executed"

       | ${all units}= | Get Units
       | ::FOR           | ${unit}     | IN | ${all units}
                          | Collect Logs And Alarms
Of Unit
 | ${unit} |
   "Collect Logs And Alarms Of
" | [Arguments] |
${unit} |
       | Collect Logs Of Unit     |
${unit} |
       | Collect Alarms Of Unit | ${unit}
3* Or you could simply implement the
"Collect Logs And Alarms
After Test Executed" as:
       | Collect Logs Of All Units
       | Collect Alarms Of All Units
!!!!! We have different layers for Keyword
I agree the naming rule should be
integrated, but perhaps not in such a forced way. Actually it’s about Common
Understanding. Keyword name is about purpose, the same purpose should have the
same name. If you have the keyword "Collect Logs Of Unit", it represents the
purpose to collect all logs of a single unit. If another engineer tries to
create a new keyword for this purpose, he / she should found this keyword, or
the tool (python? keyword documentation generation?) should told him/her


  1. Pingback:Keyword abstraction (robotframework) | Robot Framework中文站