Last time I had given one Robot Basic Training at Chengdu, a quite different experience from the past. It might because of the audiences are all framework developers, they designed their testcases in a bit different way.
I found it’s very interesting, so I asked them to send me the testcase and resource file, but unfortunately I forgot what’s the funny things inside, however check the files below.
Robot Test Cases
Setting
| Value
| Value
| value
| Value
|
resource
| resource_test.html
|
|
|
|
Meta: tt
| HI
|
|
|
|
Force Tags
| forced
|
|
|
|
Default Tags
| Login
|
|
|
|
test setup
| Go To
| http://localhost:7272
|
|
|
Test teardown
| Log
| Test finished
|
|
|
suite setup
| Open Browser
| http://localhost:7272
| ie
|
|
suite teardown
| Close Browser
|
|
|
|
Variable
| Value
| Value
| Value
| Value
|
${usename_demo}
| demo
|
|
|
|
${correct_password_for_demo}
| mode
|
|
|
|
${invalid_password_for_demo}
| aaaa
|
|
|
|
Test Case
| Action
| Argument
| Argument
| Argument
| Argument
| Argument
|
login and logout
|
|
|
|
|
|
|
| Log In
| ${usename_demo}
| ${correct_password_for_demo}
|
|
|
|
| log in successfully
|
|
|
|
|
|
| log out
|
|
|
|
|
|
log in failed
| [Tags]
| login
| errorcase
|
|
|
|
| Log In
| ${usename_demo}
| ${invalid_password_for_demo}
|
|
|
|
| Log In Unsuccessfully
|
|
|
|
|
|
Ok, first, the testcase name is not good, "login and logout" is not clear in describing the feature and expected result of this feature. And "Log In" user keyword doesn’t keep align with its activity, it actually login with username and password. Also, the "Log In Successfully" actually depend on previous "Log In" keyword, since it checks if current frame includes certain strings, which it lead by "Log In", and it will have nothing to do with _log in_ success if there is no "Log In" action ahead.
Robot Test Resources
Setting
| Value
| Value
| value
| Value
|
Library
| SeleniumLibrary
|
|
|
|
Keyword
| Action
| Argument
| Argument
| Argument
| Argument
|
Log in
| [Arguments]
| ${username}
| ${password}
|
|
|
| Input Text
| username_field
| ${username}
|
|
|
| Input Text
| password_field
| ${password}
|
|
|
| Click Button
| login_button
|
|
|
|
log out
| Click Link
| logout
|
|
|
|
| Current Frame Contains
| Login Page
|
|
|
|
log in successfully
| Current Frame Contains
| Login succeeded
|
|
|
|
log in unsuccessfully
| Current Frame Contains
| Login failed
|
|
| |
And, ok, here at least the "username_field" should better be set as a variable, coz it may change when the implementation changes. Next time it may be "user_name_text_field" or others and so on, then your case may have problem.
Finally, I remembered one thing interesting is, when designing testcases, they designed one testcase which verifies the wrong links, check if there is any unauthorized access attempts via the link address, for the sake of security. I haven’t seen such design yet, and it triggered me as there are always different needs for testcase, so, do not assume your solution is definitely / obviously the best 🙂
Pingback:Interesting Robot testcase design | Robot Framework中文站
Thank you and wish you a nice Christmas too 🙂
Alice wish you will get a great Christmas !