Custom ExpectedCondition in Selenium Java - Framework Patterns

Framework Mode - Custom ExpectedCondition

Folder Structure

src/
└── test/
    └── java/
        └── com/
            └── example/
                ├── pages/
                │   └── LoginPage.java
                ├── tests/
                │   └── LoginTest.java
                ├── conditions/
                │   └── CustomExpectedConditions.java
                ├── utils/
                │   └── WebDriverFactory.java
                └── config/
                    └── TestConfig.java

Test Framework Layers

• Driver Layer: Manages WebDriver setup and teardown (e.g., WebDriverFactory).
• Page Objects: Encapsulate page elements and actions (e.g., LoginPage).
• Custom ExpectedConditions: Contains reusable custom wait conditions (e.g., CustomExpectedConditions).
• Tests: Test classes using TestNG or JUnit to run test scenarios (e.g., LoginTest).
• Utilities: Helper classes for common functions.
• Configuration: Holds environment settings and credentials (e.g., TestConfig).

Configuration Patterns

• Environment Properties: Use TestConfig class or .properties files to store URLs, credentials, and browser types.
• Browser Selection: Pass browser type as a system property or config file value to WebDriverFactory for flexible driver creation.
• Credentials Management: Store sensitive data securely outside source code, load at runtime via environment variables or encrypted files.
• Timeouts: Centralize wait time settings for explicit waits including custom ExpectedConditions.

Test Reporting and CI/CD Integration

• TestNG Reports: Use built-in TestNG HTML reports for test execution results.
• Allure Reporting: Integrate Allure for detailed, user-friendly reports with screenshots and logs.
• CI/CD Integration: Configure Jenkins, GitHub Actions, or GitLab CI to run tests on code commits and merge requests.
• Failure Screenshots: Capture screenshots on test failure to aid debugging.
• Logging: Use logging frameworks (e.g., Log4j) to record test steps and errors.

Framework Design Principles

1. Single Responsibility: Keep custom ExpectedConditions focused on one specific wait condition.
2. Reusability: Design custom conditions to be reusable across multiple tests and pages.
3. Explicit Waits: Use custom ExpectedConditions with WebDriverWait to avoid flaky tests.
4. Readability: Name custom conditions clearly to express intent (e.g., elementHasText).
5. Encapsulation: Place custom ExpectedConditions in a dedicated package to separate concerns.

Self Check

Where in this framework structure would you add a new custom ExpectedCondition for waiting until a button is enabled?

Key Result

Organize custom ExpectedConditions in a dedicated package to create clear, reusable explicit wait conditions.