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.

Practice

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