Robot Framework Dos And Don'ts
134 likes137,054 views
The document provides guidelines for creating effective test cases using the Robot Framework, focusing on good practices and anti-patterns. Key points include the importance of naming, documentation, modularity, and proper abstraction levels to enhance test case clarity and maintenance. It emphasizes avoiding complex logic, unnecessary dependencies, and synchronization issues while encouraging data-driven approaches.
Robot Framework Dos And Don'ts
- 1. Robot Framework Dos and Don'ts © Copyright Nokia Networks Creative Commons Attribution 3.0 License
- 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. Most important goals ● Easy to understand ● Easy to maintain ● Fast to execute
- 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. 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. 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. DO: Appropriate abstraction level
- 8. DON'T: Too low abstraction level
- 9. DON'T: Comments instead of abstraction
- 10. DON'T: Documentation instead of abstraction
- 11. DO: Use data-driven style to avoid repeating workflows and to represent business rules
- 12. TRY: Gherkin style (ATDD/BDD)
- 13. DON'T: Tests without checks
- 14. AVOID: Tests with unrelated checks
- 15. AVOID: Dependencies between tests
- 16. DO: Use teardowns for cleanup
- 17. DO: Use suite setup/teardown to speed up execution
- 18. TRY: Move suite setup/teardown to directory level initialization files
- 19. DO: Use variables to avoid hard coding
- 21. AVOID: Variable assignment on test case level
- 22. AVOID: Complex logic in test data
- 23. DO: Move logic to libraries when possible
- 24. DO: Use polling to synchronize DON'T: Use sleeping to synchronize