Writing Test Script that is Easy to Understand & Maintain

Published by on | Leave a response

The primary goal of using certain conventions while writing test scripts is to increase clarity & simplicity of source code. Consistency among all projects will allow other developer to understand the code regardless of who developed the code.

I like to think the whole program through at a design level before I sit down and write any of the code…. The really great programs I’ve written have all been the ones that I have thought about for a huge amount of time before I ever wrote them…. Part of our strategy is getting the programmers to think everything through before they go to the coding phase. Writing the design document is crucial…. The worst programs are the ones where the programmers doing the work don’t lay a solid foundation…. I really hate it when I watch some people program and I don’t see them thinking.

—Bill Gates

Let’s see what we can do to write code that is easy to understand & maintain:

1. Class and Interface Names

  • The name should begin with a noun.
  • Use simple and descriptive names.
  • Try not to use acronyms, unless they are universally acceptable. If you use one, document the full name in the class comments.
  • The first letter should be upper-case in classes/interfaces names and each subsequent word in names begins with an upper-case letter
Example: OpenUserAccount
  • Use the singular term
Example: CustomerList, not Customers)

2. Method Names

  • Use full names that describe what the method does instead of using acronyms.
  • Method names should use a verb followed by a noun.
  • The first letter should be lower-case in method/function names and each subsequent word in names should begin with an upper-case letter
Example:

enterFormDetails ()

importTestData()

clickNextButton()
  • Use ‘is’ for methods that return booleans (e.g. isValid(), isEmpty())

 3. Variable Names

  1. Use camel case for variables names.
  2. The first letter of a variable name should be lowercase and the first letter of each subsequent concatenated word should be capitalized.
  3. The first letter should show the data type as below
  • b – boolean, Boolean
  • c – char, Character
  • y – byte, Byte – b is used for boolean
  • h – short, Short –
  • i – int, Integer
  • l – long, Long
  • f – float, Float
  • d – double, Double
  • s – String
Example:

String sEmpState

String sEmpZipcode

Boolean bIsDisplayed
  1. Consider using fixed Prefixes for different type of GUI objects:
  • btn – Button
  • chk – CheckBox
  • cmb – ComboBox
  • lbl – Label
  • lst – List
  • mnu – MenuBar
  • mni – MenuItem
  • opt – OptionPane
  • pnl – Panel
  • rad – RadioButton
  • tbl – Table
  • tbh – TableHeader
  • txa – TextArea
  • txt – TextField
  • txp – TextPane
  • tlb – ToolBar
  • tlt – ToolTip
  • tre – Tree
Example:

txtAmount

btnCancel

btnContinue

5. Constant Names

Use full English words in upper case letter with underscore between the words.

Example: TAX_RATE

6. Working with Conditional Statements

  • Add comments to ifstatement especially for nested If’s to make it easily understandable and manageable.

7. Working with loops

  • Each control statement should have an explanation of its purpose and the expected results.
  • Each loop, especially those used for reading records from data sheets should provide details at the beginning about loop logic.

8. Keywords

  • Decide some basic principle to name the keywords in Keyword Driven Testing.
  • Decide on Vocabulary and Phrases – One of your first tasks should be to decide on the Verbs you want to handle in your application and your domain.
  • If there are multiple application areas being handled, it is better to have each type of keyword under its own section.

9. Comments

  • If possible don’t mix Comment and code in the same line. If comment is on the same line, it should precede the statement.
  • Keep the length of the commenting line to the length permitted by the screen.
  • As far as possible, do not spread the comment across multiple lines. Each commenting line should be self-contained.
  • Use Javadoc comments at the start of each class & method to provide short detail about the purpose.
/** ***************************************************************
Functionality :

Created by :

Date created : 
 ******************************************************************
Change History

Date Modified :          Modified By :        Comments :
 ******************************************************************
 */

10. Additional Guidelines:

For additional coding guidelines and recommendations please reference the following:

Article written by

Please comment with your real name using good manners.

Leave a Reply