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
moves".
               amateur only need to care at this
level.
 

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

————————————————————————————–
=======> information
above describes how we enable user’s moves.
              people who
maintains this need to know the details.
 
If you have
e.g.
    | 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
Units
"

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

   "Collect Alarms Of All
Units
"

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

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

// if you put this keyword at the end of test case,
it means "after test executed" already, no need to repeat in the keyword
name.
// better to explicitly mention it’s for "all
units"
 
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
Unit
" | [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
Abstraction!
 
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
so.

一条评论

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

发表评论

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据