Sunday, February 12, 2012

RobotFramework Standards

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