RobotFramework team has given guidelines --> HowToWriteGoodTestCasesWithExamples. Similar to coding standards, Automation team should use certain guidelines for Keyword-Driven framework also. It would be more useful to functional team as well as other teams.
Test Suite / Script
- Test Script names should be less than 20 characters and file type should be HTML.
- It should be easily readable and self-explanatory.
- Remember that suite names are created automatically from file/directory names. Extensions are stripped, underscores are converted to spaces and, if name is all lower case, words are capitalized. For example login_tests.html -> Login Tests and DHCP_and_DNS -> DHCP and DNS.
- Documentation should be updated with purpose of the script and pre-conditions.
- Proper keywords should be given for Suite Setup, Suite Teardown, Test Setup and Test Teardown.
- Should not have too many tests (max 50) in one suite unless they are data-driven.
TestCases / Tests
- Test case names should be less than 40 characters and file type should be HTML.
- Test case Name should be in camel case (In a word, First letter is capital and remaining letters are in small).
- It should be easily readable and self explanatory.
- Documentation should be updated with manual test case steps, notes and pre-conditions.
- Proper keywords should be given for Suite Setup, Suite Teardown, Test Setup and Test Teardown.
- Appropriate tags should be given for each case.
- Tests should be independent.
- In dependant tests, detailed notes should be given. Consider verifying the status of the previous test using ${PREV TEST STATUS} variable.
- Hard coding of object name should be avoided.
- Should contain many high level keywords instead of repeating steps often.
- High level keywords should be used for navigation.
- Local variables should have prefix char ‘t’ as temporary variables
Resources
- Keep all resource files in single folder.
- Resource file names should be less than 20 characters and file type should be HTML.
- All characters should be small characters.
- Documentation should be updated with purpose.
- All constants should be maintained in separate resource file.
- Keep separate resource files for application’s data.
- Keep separate resource files for all GUI objects page wise or module-wise.
- Group the high level keywords by categories like business logic, module and general.
High Level Keyword / User Keyword / Function
- Function names should be less than 35 characters.
- It should be easily readable and self explanatory.
- For easy readability, it should be in camel case (Capital & Small letters).
- Prefixes are sometimes useful. For example, Is - to ask a question about something, Get - get a value, Set - set a value
- Can have space for better readability.
- Documentation should have clear details for purpose, variables and returning values.
- Hard coding of object name should be avoided.
- Arguments should have char ‘p’ as prefix and returned variable should have char ‘r’ as prefix.
- Local variables should have prefix char ‘t’ as temporary variables
- Duplicate Functions should not be added.
- Can contain some programming logic (for loops, if/else)
- Complex logic in libraries rather than in user keywords
- Important variables can have comments on the RHS
Variables
- Variable names should be less than 20 characters.
- Variables should have meaningful words
- For easy readability, it should be in camel case (Capital & Small letters).
- Local variables should have prefix char ‘t’ as temporary variables
- Arguments should have char ‘p’ as prefix and returned variable should have char ‘r’ as prefix.
- GUI object variables should have char ‘o’ as prefix.
- Constant variables should be in Capital letters. For example, APP_URL, DB_SERVER. All other type of variables should have mixed style (small and capital) characters.
- Script/Global variables should be defined at the top of the script.
- Function / test case level variables should be defined at top of the function.
- Can have space. But try to restrict for minimum
