加载中…
个人资料
徐毅-Kaveri
徐毅-Kaveri 新浪个人认证
  • 博客等级:
  • 博客积分:0
  • 博客访问:58,668
  • 关注人气:77
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
谁看过这篇博文
加载中…
正文 字体大小:

Keyword abstraction (robotframework)

(2009-08-25 14:51:52)
标签:

杂谈

分类: 测试和TA
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 LogOf 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.


0

阅读 评论 收藏 转载 喜欢 打印举报/Report
  • 评论加载中,请稍候...
发评论

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

      

    新浪BLOG意见反馈留言板 电话:4000520066 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有