Bird
Raised Fist0
Selenium Javatesting~15 mins

Custom ExpectedCondition in Selenium Java - Build an Automation Script

Choose your learning style10 modes available
Wait for a specific text to appear in an element using a custom ExpectedCondition
Preconditions (2)
Step 1: Locate the element with id 'status-message'
Step 2: Wait up to 10 seconds for the element's text to become exactly 'Completed'
Step 3: Verify that the element's text is 'Completed'
✅ Expected Result: The wait completes successfully when the element's text is 'Completed', and the assertion confirms the text matches
Automation Requirements - Selenium WebDriver with Java
Assertions Needed:
Assert that the element's text equals 'Completed' after waiting
Best Practices:
Use a custom ExpectedCondition class or lambda for waiting
Use WebDriverWait with explicit waits instead of Thread.sleep
Use By.id locator for element identification
Handle possible timeout exceptions gracefully
Automated Solution
Selenium Java
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.support.ui.ExpectedCondition;
import org.openqa.selenium.support.ui.WebDriverWait;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.TimeoutException;
import java.time.Duration;
import static org.junit.jupiter.api.Assertions.assertEquals;

public class CustomExpectedConditionTest {
    private WebDriver driver;

    public CustomExpectedConditionTest(WebDriver driver) {
        this.driver = driver;
    }

    public void waitForTextToBeCompleted() {
        By statusMessageLocator = By.id("status-message");

        WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));

        // Custom ExpectedCondition using lambda
        ExpectedCondition<Boolean> textIsCompleted = drv -> {
            WebElement element = drv.findElement(statusMessageLocator);
            return "Completed".equals(element.getText());
        };

        try {
            wait.until(textIsCompleted);
            WebElement statusElement = driver.findElement(statusMessageLocator);
            assertEquals("Completed", statusElement.getText(), "Status message text should be 'Completed'");
        } catch (TimeoutException e) {
            throw new AssertionError("Timed out waiting for text to be 'Completed'", e);
        }
    }
}

The code defines a method waitForTextToBeCompleted that waits up to 10 seconds for the element with id status-message to have the exact text Completed.

We use WebDriverWait with a custom ExpectedCondition implemented as a lambda. This lambda checks the element's text and returns true only when it matches Completed.

If the wait succeeds, we assert the text is exactly Completed. If the wait times out, we throw an assertion error with a clear message.

This approach avoids using Thread.sleep, uses explicit waits, and follows best practices for element locating and exception handling.

Common Mistakes - 4 Pitfalls
Using Thread.sleep instead of explicit waits
Hardcoding XPath or CSS selectors that are brittle
Not handling TimeoutException when wait fails
Checking element text without waiting
Bonus Challenge

Now add data-driven testing with 3 different expected texts: 'Completed', 'Failed', 'Pending'

Show Hint

Practice

(1/5)
1. What is the main purpose of creating a Custom ExpectedCondition in Selenium Java?
easy
A. To automatically generate test reports
B. To replace the WebDriverWait class entirely
C. To speed up test execution by skipping waits
D. To define a specific condition that WebDriverWait will wait for before proceeding

Solution

  1. Step 1: Understand the role of ExpectedCondition

    ExpectedCondition defines a condition that WebDriverWait checks repeatedly until it returns a non-null value or true.
  2. Step 2: Purpose of Custom ExpectedCondition

    Creating a custom one allows you to specify your own logic for waiting, beyond built-in conditions.
  3. Final Answer:

    To define a specific condition that WebDriverWait will wait for before proceeding -> Option D
  4. Quick Check:

    Custom ExpectedCondition = Custom wait logic [OK]
Hint: Custom ExpectedCondition defines what to wait for [OK]
Common Mistakes:
  • Thinking it replaces WebDriverWait
  • Assuming it speeds up tests by skipping waits
  • Confusing it with reporting features
2. Which method must be implemented when creating a custom ExpectedCondition in Selenium Java?
easy
A. apply(WebDriver driver)
B. waitForCondition()
C. checkCondition(WebElement element)
D. execute()

Solution

  1. Step 1: Recall ExpectedCondition interface

    The ExpectedCondition interface requires implementing the apply method that takes a WebDriver and returns a result or null.
  2. Step 2: Identify correct method name

    Only apply(WebDriver driver) is the correct method signature for custom conditions.
  3. Final Answer:

    apply(WebDriver driver) -> Option A
  4. Quick Check:

    Custom ExpectedCondition method = apply() [OK]
Hint: Custom ExpectedCondition always implements apply(driver) [OK]
Common Mistakes:
  • Using wrong method names like waitForCondition or execute
  • Confusing with WebElement methods
  • Missing the WebDriver parameter
3. Given the following custom ExpectedCondition code snippet, what will be the output if the element with id 'status' has text 'Ready'?
ExpectedCondition<Boolean> condition = driver -> {
  WebElement el = driver.findElement(By.id("status"));
  return el.getText().equals("Ready") ? true : null;
};
WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(5));
boolean result = wait.until(condition);
medium
A. The code will cause a compilation error
B. The wait will pass and result will be true
C. The wait will pass and result will be null
D. The wait will timeout and throw TimeoutException

Solution

  1. Step 1: Analyze the condition logic

    The condition returns true if the element's text equals "Ready", otherwise null.
  2. Step 2: Understand WebDriverWait behavior

    WebDriverWait waits until the condition returns a non-null, true value. Since text is "Ready", condition returns true immediately.
  3. Final Answer:

    The wait will pass and result will be true -> Option B
  4. Quick Check:

    Condition true means wait passes [OK]
Hint: If condition returns true, wait.until returns true [OK]
Common Mistakes:
  • Thinking null return means pass
  • Assuming wait throws error on true
  • Confusing null with false
4. Identify the error in this custom ExpectedCondition implementation:
ExpectedCondition<Boolean> condition = driver -> {
  WebElement el = driver.findElement(By.id("submit"));
  if(el.isDisplayed()) {
    return true;
  } else {
    return false;
  }
};
medium
A. findElement should be replaced with findElements
B. Using lambda expression is not allowed for ExpectedCondition
C. Returning false instead of null causes wait.until to stop waiting prematurely
D. Missing try-catch block for NoSuchElementException

Solution

  1. Step 1: Understand ExpectedCondition return rules

    ExpectedCondition should return null to continue waiting, true to stop waiting successfully.
  2. Step 2: Analyze the code's return values

    Returning false causes wait.until to stop waiting and throw TimeoutException immediately, which is not desired.
  3. Final Answer:

    Returning false instead of null causes wait.until to stop waiting prematurely -> Option C
  4. Quick Check:

    Return null to keep waiting, not false [OK]
Hint: Return null to wait longer, not false [OK]
Common Mistakes:
  • Returning false instead of null to continue wait
  • Assuming lambda is invalid
  • Ignoring exception handling
5. You want to create a custom ExpectedCondition that waits until a list of elements with class 'item' contains at least 3 visible elements. Which implementation correctly achieves this?
hard
A. ExpectedCondition<Boolean> condition = driver -> { List<WebElement> items = driver.findElements(By.className("item")); long visibleCount = items.stream().filter(WebElement::isDisplayed).count(); return visibleCount >= 3 ? true : null; };
B. ExpectedCondition<Boolean> condition = driver -> { List<WebElement> items = driver.findElements(By.className("item")); int count = 0; for(WebElement item : items) { if(item.isDisplayed()) count++; } return count > 3 ? true : false; };
C. ExpectedCondition<Boolean> condition = driver -> { List<WebElement> items = driver.findElements(By.className("item")); return items.size() >= 3; };
D. ExpectedCondition<Boolean> condition = driver -> { List<WebElement> items = driver.findElements(By.className("item")); return items.stream().allMatch(WebElement::isDisplayed); };

Solution

  1. Step 1: Understand the requirement

    Wait until at least 3 elements with class 'item' are visible (isDisplayed() true).
  2. Step 2: Analyze each option

    ExpectedCondition<Boolean> condition = driver -> { List<WebElement> items = driver.findElements(By.className("item")); long visibleCount = items.stream().filter(WebElement::isDisplayed).count(); return visibleCount >= 3 ? true : null; }; counts visible elements and returns true if count >= 3, else null to keep waiting. This matches requirement and wait logic.
    ExpectedCondition<Boolean> condition = driver -> { List<WebElement> items = driver.findElements(By.className("item")); int count = 0; for(WebElement item : items) { if(item.isDisplayed()) count++; } return count > 3 ? true : false; }; returns false if count is not > 3, which stops wait prematurely.
    ExpectedCondition<Boolean> condition = driver -> { List<WebElement> items = driver.findElements(By.className("item")); return items.size() >= 3; }; checks total size, ignoring visibility.
    ExpectedCondition<Boolean> condition = driver -> { List<WebElement> items = driver.findElements(By.className("item")); return items.stream().allMatch(WebElement::isDisplayed); }; waits until all are visible, not at least 3.
  3. Final Answer:

    Option A correctly waits for at least 3 visible elements -> Option A
  4. Quick Check:

    Return true if condition met, else null to wait [OK]
Hint: Return true if condition met, else null to wait [OK]
Common Mistakes:
  • Returning false instead of null to continue wait
  • Ignoring visibility check
  • Checking all elements visible instead of at least 3
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard