Attente explicite (explicit wait)

Une attente explicite met un test en pause jusqu’à ce qu’une condition donnée soit vraie, en la vérifiant à intervalles réguliers et en échouant sur un timeout si elle ne se réalise jamais. Elle est « explicite » parce que vous l’écrivez à l’endroit exact où le test doit attendre, et que vous précisez ce qu’il faut attendre. Avec Selenium 4, cela signifie WebDriverWait combiné à une condition issue de ExpectedConditions ou à une lambda.

Exemple (Selenium 4, Java)

import java.time.Duration;
import org.openqa.selenium.By;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;

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

WebElement save = wait.until(
    ExpectedConditions.elementToBeClickable(By.id("save")));
save.click();

wait.until(ExpectedConditions.textToBePresentInElementLocated(
    By.cssSelector("[role='status']"), "Saved"));

// Any condition can be a lambda that returns a non-null or true value
wait.until(d -> d.findElements(By.cssSelector(".result-row")).size() == 20);

Par défaut, WebDriverWait interroge toutes les 500 ms et ignore NotFoundException pendant ce temps. Pour un autre intervalle ou d’autres exceptions à ignorer, utilisez FluentWait (withTimeout, pollingEvery, ignoring).

Différence avec une attente implicite

Une attente implicite est un réglage global unique qui fait que chaque appel à findElement réessaie jusqu’à ce que l’élément existe. Elle ne sait rien de la visibilité, de la cliquabilité ni du texte. Une attente explicite cible une condition à un endroit précis du test : elle peut donc attendre exactement l’état dont vous avez besoin, comme la disparition d’un spinner ou l’activation d’un bouton.

La documentation de Selenium déconseille de mélanger les deux, car la combinaison des timeouts peut produire des durées d’attente imprévisibles. La plupart des équipes laissent l’attente implicite à zéro et utilisent des attentes explicites partout.

Erreurs courantes

• Thread.sleep au lieu d’une attente. Une pause fixe est soit trop courte (test flaky), soit trop longue (test lent), et généralement les deux selon la machine.
• Attendre la présence quand il faut la visibilité. presenceOfElementLocated réussit dès que le nœud est dans le DOM, même s’il est masqué.
• Conserver un WebElement à travers un nouveau rendu. Attendez sur un locator By pour que l’élément soit retrouvé après la modification du DOM.
• Créer dans chaque helper une nouvelle attente avec un timeout énorme. Centralisez une valeur par défaut raisonnable dans votre framework.