Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Robot Framework 
Dos and Don'ts 
© Copyright Nokia Networks 
Creative Commons Attribution 3.0 License
Introduction 
● Robot Framework is a generic acceptance level test 
automation framework 
● This presentation demonstrates...
Most important goals 
● Easy to understand 
● Easy to maintain 
● Fast to execute
Naming 
● Very important to name well test cases, test 
suites, keywords, variables, libraries, resource 
files, ... 
● Go...
Documentation 
● Test suites often benefit from documentation 
explaining background etc. 
● Well named tests created usin...
Example categorization 
● DO: A very good and generally recommended 
practice. 
● DON'T: An anti-pattern, should not be us...
DO: Appropriate abstraction level
DON'T: Too low abstraction level
DON'T: Comments instead of 
abstraction
DON'T: Documentation instead of 
abstraction
DO: Use data-driven style to avoid 
repeating workflows and to 
represent business rules
TRY: Gherkin style (ATDD/BDD)
DON'T: Tests without checks
AVOID: Tests with unrelated checks
AVOID: Dependencies between 
tests
DO: Use teardowns for cleanup
DO: Use suite setup/teardown to 
speed up execution
TRY: Move suite setup/teardown to 
directory level initialization files
DO: Use variables to avoid hard 
coding
DON'T: Overuse variables
AVOID: Variable assignment on test 
case level
AVOID: Complex logic in test data
DO: Move logic to libraries when 
possible
DO: Use polling to synchronize 
DON'T: Use sleeping to synchronize
Upcoming SlideShare
Loading in …5
×

Robot Framework Dos And Don'ts

77,499 views

Published on

This presentation demonstrates general guidelines how to create good test cases using Robot Framework. Both good practices and anti-patterns are presented.

The presentation is hosted on GitHub where you can find the original in ODP format: https://github.com/robotframework/DosDontsSlides

Published in: Technology

Robot Framework Dos And Don'ts

  1. 1. Robot Framework Dos and Don'ts © Copyright Nokia Networks Creative Commons Attribution 3.0 License
  2. 2. Introduction ● Robot Framework is a generic acceptance level test automation framework ● This presentation demonstrates general guidelines how to create good test cases using it ● Both good practices and anti-patterns are presented ● See also http://code.google.com/p/robotframework/wiki/HowTo WriteGoodTestCases
  3. 3. Most important goals ● Easy to understand ● Easy to maintain ● Fast to execute
  4. 4. Naming ● Very important to name well test cases, test suites, keywords, variables, libraries, resource files, ... ● Good name is explicit and easy to understand ● Consistency ● Namespaces ● Name should tell “what”, not “how”
  5. 5. Documentation ● Test suites often benefit from documentation explaining background etc. ● Well named tests created using well named keywords should not need extra documentation ● Reusable keywords must be documented – Good keyword and argument names help and are often adequate with higher-level keywords – Library keywords need detailed documentation
  6. 6. Example categorization ● DO: A very good and generally recommended practice. ● DON'T: An anti-pattern, should not be used. ● TRY: A practice that works in many contexts. ● AVOID: A practice that typically should be avoided but may sometimes be necessary.
  7. 7. DO: Appropriate abstraction level
  8. 8. DON'T: Too low abstraction level
  9. 9. DON'T: Comments instead of abstraction
  10. 10. DON'T: Documentation instead of abstraction
  11. 11. DO: Use data-driven style to avoid repeating workflows and to represent business rules
  12. 12. TRY: Gherkin style (ATDD/BDD)
  13. 13. DON'T: Tests without checks
  14. 14. AVOID: Tests with unrelated checks
  15. 15. AVOID: Dependencies between tests
  16. 16. DO: Use teardowns for cleanup
  17. 17. DO: Use suite setup/teardown to speed up execution
  18. 18. TRY: Move suite setup/teardown to directory level initialization files
  19. 19. DO: Use variables to avoid hard coding
  20. 20. DON'T: Overuse variables
  21. 21. AVOID: Variable assignment on test case level
  22. 22. AVOID: Complex logic in test data
  23. 23. DO: Move logic to libraries when possible
  24. 24. DO: Use polling to synchronize DON'T: Use sleeping to synchronize

×