Custom ExpectedCondition in Selenium Java - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this custom ExpectedCondition?

Consider the following Java Selenium code snippet defining a custom ExpectedCondition. What will be the result of calling apply(driver) if the element with id 'status' has text 'Complete'?

Selenium Java

ExpectedCondition<Boolean> isStatusComplete = new ExpectedCondition<Boolean>() {
    public Boolean apply(WebDriver driver) {
        WebElement status = driver.findElement(By.id("status"));
        return "Complete".equals(status.getText());
    }
};

// Assume driver.findElement(By.id("status")).getText() returns "Complete"

A true

B false

C TimeoutException is thrown

D NoSuchElementException is thrown

💡 Hint

Think about what the apply method returns when the element text matches "Complete".

The apply method returns true if the element's text equals "Complete". Since the element's text is "Complete", the method returns true.

❓ assertion

intermediate

Which assertion correctly verifies the custom ExpectedCondition?

Given a custom ExpectedCondition named isButtonEnabled that returns true when a button is enabled, which assertion correctly verifies this condition in a test?

Selenium Java

ExpectedCondition<Boolean> isButtonEnabled = driver -> driver.findElement(By.id("submitBtn")).isEnabled();

A assertNull(isButtonEnabled.apply(driver));

B assertTrue(isButtonEnabled.apply(driver));

C assertEquals(isButtonEnabled, true);

D assertFalse(isButtonEnabled.apply(driver));

💡 Hint

Remember to call apply(driver) to get the boolean result before asserting.

The apply method returns a Boolean, so assertTrue with isButtonEnabled.apply(driver) correctly asserts the condition is true.

🔧 Debug

advanced

Why does this custom ExpectedCondition cause a NoSuchElementException?

Examine the custom ExpectedCondition below. Why might it throw NoSuchElementException during execution?

Selenium Java

ExpectedCondition<Boolean> isVisible = driver -> {
    WebElement elem = driver.findElement(By.cssSelector(".my-element"));
    return elem.isDisplayed();
};

A Because findElement throws NoSuchElementException if the element is not found immediately

B Because isDisplayed() throws NoSuchElementException if element is hidden

C Because the lambda syntax is invalid and causes runtime error

D Because ExpectedCondition must return WebElement, not Boolean

💡 Hint

Consider what happens if the element is not present in the DOM when findElement is called.

findElement throws NoSuchElementException immediately if the element is not found. The ExpectedCondition should handle this or use findElements.

❓ framework

advanced

Which custom ExpectedCondition implementation correctly waits for an element's text to contain a substring?

Select the correct custom ExpectedCondition that waits until the element with id 'message' contains the substring 'Success'.

A

ExpectedCondition<Boolean> textContains = driver -> {
    WebElement el = driver.findElement(By.id("message"));
    return el.getText().equals("Success");
};

B ExpectedCondition<Boolean> textContains = driver -> driver.findElement(By.id("message")).getText().startsWith("Success");

C ExpectedCondition<Boolean> textContains = driver -> driver.findElement(By.id("message")).getText().contains("Success");

D ExpectedCondition<Boolean> textContains = driver -> driver.findElement(By.id("message")).getText().endsWith("Success");

💡 Hint

Look for the condition that checks if the text contains the substring, not equals or starts/ends with it.

Option C correctly checks if the element's text contains the substring "Success".

🧠 Conceptual

expert

What is the main advantage of using a custom ExpectedCondition in Selenium tests?

Why would a tester create a custom ExpectedCondition instead of using built-in ones?

A To automatically retry failed tests without coding

B To reduce test execution time by skipping waits

C To avoid using WebDriverWait entirely

D To wait for complex or specific conditions not covered by built-in ExpectedConditions

💡 Hint

Think about situations where built-in conditions are not enough.

Custom ExpectedConditions allow waiting for specific or complex states that built-in ones do not support.