In this article, we will look at some of the industry best practices and standards to use in order to develop and maintain effective test automation strategies with Selenium.
1. Naming Convention
When developing the framework, it is important to establish some naming convention standards for each type of file created. In general, this is completely subjective. But it is important to establish them upfront so users can use the same file naming conventions for the same file types to avoid confusion later on, when there are many users building them. Here are a few suggestions:
- Utility classes: Utility classes don’t use any prefix or suffix in their names, but do follow Java standards such as having the first letter of each word capitalized, and ending with .java extensions. (Acronyms used can be all caps). Examples include CreateDriver.java, Global_VARS.java, BrowserUtils.java, DataProvider_JSON.java, and so on.
- Page object classes: It is useful to be able to differentiate the page object classes from the utility classes. A good way to name them is FeaturePO.java, where PO stands for page object and is capitalized, along with the first letter of each word. End the name with a .java extension.
- Test classes: It is useful to be able to differentiate the test classes from the PO and utility classes. A good way to name them is FeatureTest.java, where Test stands for test class, and the first letter of each word is capitalized. End the name with a .java extension.
- Data files: Data files are obviously named with an extension for the type of file, such as .json, .csv, .xls, and so on. But, in the case of this framework, the files can be named the same as the corresponding test class, but without the word Test. For example, LoginCredsTest.java would have the data file LoginCreds.json.
- Setup classes: Usually, there is a common setup class for setup and teardown for all test classes, that can be named AUTSetup.java. So, as an example, GmailSetup.java would be the setup class for all test classes derived from it, and contains only TestNG annotated methods.
- Test methods: Most test methods in each test class are named using sequential numbering, followed by a feature and action. For example: tc001_gmailLoginCreds, tc002_gmailLoginPassword, and so on.
- Setup/teardown methods: The setup and teardown methods can be named according to the setup or teardown action they perform. The following naming conventions can be used in conjunction with the TestNG annotations:
- @BeforeSuite: The suiteSetup method
- @AfterSuite: The suiteTeardown method
- @BeforeClass: The classSetup method
- @AfterClass: The classTeardown method
- @BeforeMethod: The methodSetup method
- @AfterMethod: The methodTeardown method
2. Comments
Although obvious and somewhat subjective, it is good practice to comment on code when it is not obvious why something is done, there is a complex routine, or there is a “kluge” added to work around a problem. In Java, there are two types of comments used, as well as a set of standards for JavaDoc. We will look at a couple of examples here:
[box type=”info” align=”” class=”” width=””]There is an Oracle article on using comments in Java located at http://www. oracle.com/ technetwork/java/codeconventions-141999.html#385[/box]
Block comment:
/* single line block comment */
code goes here…
/*
* multi-line block
* comment
*/
code goes here...
End-of-line comment:
code goes here // end of line comment
JavaDoc comments:
/**
* Description of the method
*
* @param arg1 to the method
* @param arg2 to the method
* return value returned from the method
*/[box type=”info” align=”” class=”” width=””]The Oracle documentation on using the JavaDoc tool is located at http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html. [/box]
3. Folder names and structures
As the framework starts to evolve, there needs to be some organization around the folder structure in the IDE, along with a naming convention. The IntelliJ IDE uses modules to organize the repo, and under those modules, users can create the folder structures. It is common to also separate the page object and utility classes from the test classes.
So, as an example, under the top-level folder src, create main/java/com/yourCo/page objects and test/java/com/yourCo/tests folders. From there, under each structure, users can create feature-based folders.
Also, to retain a completely independent set of libraries for the Selenium driver and utility classes, create a separate module called something like Selenium3 with the same folder structures. This will allow users to use the same driver class and utilities for any additional modules that are added to the repo/framework. It is common to automate testing for more than one application, and this will allow the inclusion of the module in those additional modules. Here are a few suggestions regarding folder naming conventions:
- Name all the folders using lowercase names, so there won’t be a mix-and-match of different standards.
- Name the page object class folders after the features they pertain to; for instance, login for the LoginPO.java, email for the GmailPO.java, and so on.
- Name the test class folders after the same features as the PO classes, but under the test folder. Then there can be a one-to-one correlation between the PO and test class folders.
- Store the common base classes under a common folder under main.
- Store the common setup classes under a common folder under test.
- Store all the utility classes for the AUT under a utils folder under main.
- Store all the suite files for the tests under a suites folder under test.
Here is an example of a folder structure for the Selenium3 module. Of course, there are no test folders under this one:
Here is an example of a folder structure for an AUT module showing the PO and test class Folders:
You read an excerpt from the book Selenium Framework Design in Data-Driven Testing written by Carl Cocchiaro. This book presents effective techniques for building data-driven test frameworks using Selenium WebDriver.
