Java Naming Conventions for Test Automation Engineers

Chamila Ambahera
3 min readSep 8, 2024

--

You might have a question about why different Java naming convention for Automation Engineers. :)

This is the same naming convention followed by many industry-leading companies. But I optimized it for Test Automation Engineers. Also, I have added examples that you are more familiar with.

Introduction

Using naming conventions improves readability, making code easier to understand and maintain. It enhances consistency, which helps reduce errors and confusion in large projects. Naming conventions support collaboration by making it easier for teams to work together, and they promote maintainability, allowing for easier updates and refactoring. They also serve as self-documentation, clarifying the intent of the code without extra comments, and help ensure scalability in growing projects.

Java Naming Conventions

When developing an automation framework in Java, following standard naming conventions helps ensure code readability, maintainability, and consistency. Below are some key Java naming conventions to follow:

1. Packages

  • Naming Style: Use all lowercase letters with a period (`.`) to separate hierarchical components.
  • Convention: Use your organization’s domain in reverse as the root package, followed by descriptive names for different modules.
  • Examples:
 com.testtacticx.automation.pages
com.testtacticx.automation.utils
com.testtacticx.automation.config

2. Classes

  • Naming Style: Use PascalCase (UpperCamelCase) for class names. Each word should start with a capital letter, and the name should be descriptive and noun-based.
  • Convention: Class names should be clear, concise, and represent what the class does.
  • Examples:
 LoginPage
HomePage
TestBase
BrowserFactory
ReportManager

3. Methods

  • Naming Style: Use camelCase for method names. The first word starts with a lowercase letter, and subsequent words are capitalized.
  • Convention: Method names should describe the action or behaviour they perform and typically start with a verb.
  • Examples:
 public void loginToApplication() {}
public void clickSubmitButton() {}
public String getUserName() {}
public void setUserName(String username) {}

4. Variables

  • Naming Style: Use camelCase for variable names. Start with a lowercase letter and subsequent words are capitalized.
  • Convention: Variables should have meaningful, self-explanatory names that represent their purpose or content.
  • Examples:
 String userName;
int maxTimeout;
WebDriver driver;
List<String> testData;

5. Constants

  • Naming Style: Use ALL_CAPS with underscores (`_`) to separate words.
  • Convention: Constants should be declared `static final` and placed in a separate class (e.g., `Constants.java`) or inside relevant classes.
  • Examples:
 public static final int DEFAULT_TIMEOUT = 30;
public static final String BASE_URL = “https://example.com";

6. Interfaces

  • Naming Style: Use PascalCase (UpperCamelCase) for interface names, similar to class names. Interface names often describe a capability and are typically adjectives or nouns.
  • Convention: Avoid prefixing the interface name with `I` (e.g., `IDriver`). Instead, use meaningful names.
  • Examples:
 WebDriver
TestRunner
ScreenshotCapture

7. Test Classes

  • Naming Style: Use PascalCase to test class names. End the class name with `Test` to indicate it contains test cases.
  • Convention: Test classes should represent the functionality or module they are testing.
  • Examples:
 LoginTest
HomePageTest
SearchFunctionalityTest

8. Test Methods

  • Naming Style: Use camelCase for method names. Test method names should be descriptive, indicating the purpose of the test, the scenario being tested, and the expected behaviour.
  • Convention: Follow the format “methodName_condition_expectedOutcome” or similar.
  • Examples:
 public void loginWithValidCredentials() {}
public void loginWithInvalidCredentials() {}
public void verifyHomePageTitle() {}

9. Locators (POM Elements)

  • Naming Style: Use camelCase for naming locators, typically following the structure of the page element.
  • Convention: Use descriptive names for locators to indicate the element they represent.
  • Examples:
 private Locator usernameField;
private Locator passwordField;
private Locator loginButton;

10. Enums

  • Naming Style: Use PascalCase for enum names and ALL_CAPS for enum constants.
  • Convention: Enum names should represent the category or type they are defining, and enum constants should describe the individual values.
  • Examples:
public enum BrowserType {
CHROME,
FIREFOX,
EDGE,
SAFARI
}

public enum Environment {
DEV,
STAGING,
PROD
}

11. Annotations

  • Naming Style: For custom annotations, use PascalCase and prefix with `@`.
  • Examples:
 @BeforeMethod
@AfterTest
@DataProvider
@Test

12. File Names

  • Naming Style: Use PascalCase for file names, matching the class name.
  • Convention: The file name should exactly match the class or interface name it contains.
  • Examples:
LoginPage.java
TestBase.java
BrowserFactory.java

13. Packages for Utilities and Helpers

  • Naming Style: Use camelCase for package names. Avoid deep nesting, and group utilities logically.
  • Examples:
 com.testtacticx.automation.utils
com.testtacticx.automation.helpers

14. Exception Handling

  • Naming Style: Use PascalCase for custom exception class names. End the class name with `Exception`.
  • Examples:

public class InvalidLoginException extends Exception {}
public class ElementNotFoundException extends RuntimeException {}

15. Loggers

  • Naming Style: Use camelCase for log variables.
  • Convention: Use a logger variable that reflects the class, typically `log`.
  • Example :
private static final Logger log = LoggerFactory.getLogger(LoginPage.class);

By adhering to these conventions, your automation framework will be clean, maintainable, and easy for other developers to understand and contribute to.

--

--

Chamila Ambahera
Chamila Ambahera

Written by Chamila Ambahera

Principle Automation Engineer | Arctic Code Vault Contributor | Trained Over 500 engineers

Responses (1)