Best Practices for Naming Artifacts/Folders in Opkey :

In test automation using Opkey, consistency is key, and an organized naming convention strategy is essential for maintaining clarity and efficiency in managing variables, folders, methods, and test cases. A clear and standardized naming convention enhances communication within the team, eases maintenance, and improves test scalability. Below are best practices for defining and using naming conventions across different Opkey components.

1. Naming Conventions for Variables

Variables are central to test automation, and having a proper naming strategy ensures that they are easy to understand and manage.

Best Practices:

Use Descriptive Names: Variable names should clearly indicate their purpose and meaning. Avoid generic names like x, data1, or temp. Instead, use descriptive names like customerName, invoiceNumber, or loginPassword.
Avoid Long Names: While it's essential to be descriptive, avoid excessively long variable names. Aim for a balance by using succinct but meaningful names (e.g., orderID instead of customerOrderIdentificationNumber).
Use CamelCase: For multi-word variable names, adopt CamelCase notation, where the first word is lowercase, and subsequent words are capitalized. Example: firstName, customerAddress.
Prefix for Contextual Clarity: In cases where the same variable name might apply in different contexts, use a prefix to provide clarity. For instance:
- inputCustomerName (for input data)
- expectedCustomerName (for expected results)
Avoid Special Characters and Spaces: Stick to alphanumeric characters and underscores (_). Special characters or spaces can cause errors or confusion.

Example:

Instead of temp123 → Use userPassword
Instead of x → Use orderAmount

2. Naming Conventions for Folders

Organizing your folders well ensures quick navigation through your test artifacts. A logical folder structure is essential for managing test cases, methods, and other components.

Best Practices:

Group by Module/Feature: Organize folders based on application modules or features. For example, folders like Login, Payments, Orders, and Inventory provide a clear categorization of tests related to specific features.
Hierarchical Structure: Use a hierarchical folder structure to further divide major modules into sub-features or processes. For example: Order>Createorder>UpdateOrder>CancelOrder
Include Context in Names: Folder names should provide context about the functionality they store. Use clear and concise terms that indicate what test cases or methods are contained within the folder.
Use Consistent Terminology: If certain terms are used in folder names, be consistent. For instance, if you use Create for one module, don't switch to Add in another.

Example:

Instead of Tests → Use Orders/CreateOrder
Instead of NewFolder1 → Use Payments/RefundProcessing

3. Naming Conventions for Methods

Methods represent reusable actions or operations in test automation. In Opkey, we use API test methods. Proper naming ensures that team members can quickly identify what each method does.

Best Practices:

Action-Oriented Names: Use verbs that describe the action performed by the method. For example, LoginToApplication, ValidateOrderTotal, or ClickSubmitButton.
Include Object Context: Methods often interact with objects or fields. Including the object’s name provides clarity. For example, SelectDropdownOption is more useful than just SelectOption.
Prefix for Specific Actions: Consider prefixing methods with action words like Get, Set, Validate, Select, etc., to define the operation being performed.

Example:

Instead of Login → Use LoginToApplication
Instead of CheckAmount → Use ValidateOrderAmount

4. Naming Conventions for Test Cases

Test cases should have clear, descriptive names that specify the purpose of the test. This aids in understanding test coverage and identifying tests during debugging or reviews.

Best Practices:

Be Descriptive and Specific: Test case names should describe the functionality being tested in clear terms. Example: VerifyOrderCreationWithValidData, CheckLoginWithInvalidCredentials.
Use a Standard Structure: Follow a consistent structure for naming across all test cases. This makes it easier to locate test cases in your folders for all team members.
Avoid Ambiguity: Names like Test1 or Scenario123 are not helpful. Use meaningful descriptions that make it clear what’s being tested.
Include the Condition Being Tested: If your test case covers edge cases or specific conditions, include those conditions in the name. Example: VerifyPaymentFailure_InsufficientFunds.
Use Underscores for Separation: In multi-word test case names, separate sections using underscores for improved readability (e.g., Verify_Invoice_Generation_WithDiscount).

5. General Tips for All Naming Conventions

Consistency: Ensure the entire team adheres to the same conventions. This consistency minimizes confusion and ensures everyone can easily navigate the test cases and components.
Use Abbreviations Wisely: Avoid over-abbreviation in names, as they can make understanding difficult. If abbreviations must be used, ensure they are commonly known and documented (e.g., ID for Identification, Qty for Quantity).
Document the Naming Strategy: It’s important to document your naming convention strategy in an internal style guide. This ensures that everyone involved in the project understands the agreed-upon guidelines and can refer to them when in doubt.

Best Practices for Naming Artifacts/Folders in Opkey

1. Naming Conventions for Variables

Variables are central to test automation, and having a proper naming strategy ensures that they are easy to understand and manage.

Best Practices:

Use Descriptive Names: Variable names should clearly indicate their purpose and meaning. Avoid generic names like x, data1, or temp. Instead, use descriptive names like customerName, invoiceNumber, or loginPassword.

Avoid Long Names: While it's essential to be descriptive, avoid excessively long variable names. Aim for a balance by using succinct but meaningful names (e.g., orderID instead of customerOrderIdentificationNumber).

Use CamelCase: For multi-word variable names, adopt CamelCase notation, where the first word is lowercase, and subsequent words are capitalized. Example: firstName, customerAddress.

Prefix for Contextual Clarity: In cases where the same variable name might apply in different contexts, use a prefix to provide clarity. For instance:

inputCustomerName (for input data)

expectedCustomerName (for expected results)

Avoid Special Characters and Spaces: Stick to alphanumeric characters and underscores (_). Special characters or spaces can cause errors or confusion.

Example:

Instead of temp123 → Use userPassword

Instead of x → Use orderAmount

2. Naming Conventions for Folders

Organizing your folders well ensures quick navigation through your test artifacts. A logical folder structure is essential for managing test cases, methods, and other components.

Best Practices:

Group by Module/Feature: Organize folders based on application modules or features. For example, folders like Login, Payments, Orders, and Inventory provide a clear categorization of tests related to specific features.

Hierarchical Structure: Use a hierarchical folder structure to further divide major modules into sub-features or processes. For example: Order>Createorder>UpdateOrder>CancelOrder

Use Consistent Terminology: If certain terms are used in folder names, be consistent. For instance, if you use Create for one module, don't switch to Add in another.

Example:

Instead of Tests → Use Orders/CreateOrder

Instead of NewFolder1 → Use Payments/RefundProcessing

3. Naming Conventions for Methods

Methods represent reusable actions or operations in test automation. In Opkey, we use API test methods. Proper naming ensures that team members can quickly identify what each method does.

Best Practices:

Action-Oriented Names: Use verbs that describe the action performed by the method. For example, LoginToApplication, ValidateOrderTotal, or ClickSubmitButton.

Include Object Context: Methods often interact with objects or fields. Including the object’s name provides clarity. For example, SelectDropdownOption is more useful than just SelectOption.

Prefix for Specific Actions: Consider prefixing methods with action words like Get, Set, Validate, Select, etc., to define the operation being performed.

Example:

Instead of Login → Use LoginToApplication

Instead of CheckAmount → Use ValidateOrderAmount

4. Naming Conventions for Test Cases

Test cases should have clear, descriptive names that specify the purpose of the test. This aids in understanding test coverage and identifying tests during debugging or reviews.

Best Practices:

Be Descriptive and Specific: Test case names should describe the functionality being tested in clear terms. Example: VerifyOrderCreationWithValidData, CheckLoginWithInvalidCredentials.

Use a Standard Structure: Follow a consistent structure for naming across all test cases. This makes it easier to locate test cases in your folders for all team members.

Avoid Ambiguity: Names like Test1 or Scenario123 are not helpful. Use meaningful descriptions that make it clear what’s being tested.

Include the Condition Being Tested: If your test case covers edge cases or specific conditions, include those conditions in the name. Example: VerifyPaymentFailure_InsufficientFunds.

Use Underscores for Separation: In multi-word test case names, separate sections using underscores for improved readability (e.g., Verify_Invoice_Generation_WithDiscount).

5. General Tips for All Naming Conventions

Consistency: Ensure the entire team adheres to the same conventions. This consistency minimizes confusion and ensures everyone can easily navigate the test cases and components.

Use Abbreviations Wisely: Avoid over-abbreviation in names, as they can make understanding difficult. If abbreviations must be used, ensure they are commonly known and documented (e.g., ID for Identification, Qty for Quantity).

Document the Naming Strategy: It’s important to document your naming convention strategy in an internal style guide. This ensures that everyone involved in the project understands the agreed-upon guidelines and can refer to them when in doubt.