← Back to libraryQuestion 292 of 468
🏗️Framework DesignIntermediate

Wait Strategy Design

📌 Definition:

A framework needs a consistent wait strategy to handle asynchronous UIs. Explicit waits (WebDriverWait + ExpectedConditions) are preferred; implicit waits set a global poll; fluent waits customize polling/exceptions. Never use fixed Thread.sleep.

📖 Detailed Explanation:

Implicit wait sets a single global timeout for element location but doesn't wait for conditions (visible/clickable) and can interact badly with explicit waits (compounding timeouts). Explicit waits pause until a SPECIFIC condition (elementToBeClickable, visibilityOf) — the recommended approach, centralized in a WaitUtils helper so every test uses the same robust logic. Fluent waits let you tune polling interval and ignore exceptions (e.g. StaleElement). Mixing implicit and explicit waits is discouraged. A good framework exposes wait helpers (waitForVisible, waitForClickable) and bans Thread.sleep, which is the leading cause of flaky/slow suites.

🔑 Key Points:
  • Explicit waits (WebDriverWait + ExpectedConditions) — preferred
  • Implicit wait = global element-find timeout (don't mix with explicit)
  • Fluent wait tunes polling + ignored exceptions (stale)
  • Ban Thread.sleep; centralize waits in a WaitUtils helper
🌍 Real-World Example:

A WaitUtils.waitForClickable(locator) wrapper used by every page method replaces scattered Thread.sleep(3000) calls, cutting both flakiness and runtime because it proceeds the moment the element is actionable.

🎯 Scenario-Based Interview Question:

Reviewers find Thread.sleep(3000) throughout the suite. What's the framework-level fix and why is it better?