J'essaye d'écrire une boucle while qui vérifie l'attribut isDisplayed () par rapport à un élément de chargement, et affiche "il est en cours de chargement" si la fenêtre de chargement est visible. Si la fenêtre de chargement disparaît, la boucle while se fermera.
private By superPoseLoading = By.xpath("//span[@class='loading']");
while (true) {
if (driver.findElement(superPoseLoading).isDisplayed() == true) {
System.out.println("is loading");
}else {
break;
}
}
mais même si la condition if est vraie, le programme n'envoie pas le message et le cycle est interrompu.
3 Réponses :
Vous n'avez pas besoin de l'instruction if ni d'affecter true à la méthode .isDisplayed (), car elle renvoie toujours un booléen.
while (driver.findElement(superPoseLoading).isDisplayed()) {
System.out.println("is loading");
}
mais quand j'essaye une validation plus simple, comme ceci: while (driver.findElement (superPoseLoading) .isDisplayed ()) {System.out.println ("est en cours de chargement"); } ignorer le cycle même lorsque la fenêtre de chargement est présente
C'est vraiment intéressant, car avant je l'ai posté. J'ai vérifié ce code dans mes tests et il fonctionne comme prévu, continuez à imprimer "Son chargement" dans la console, j'utilisais le bouton sur la page, donc ce que je pense, c'est que ce problème avec l'élément que vous utilisez, il ne peut pas être vérifié avec la méthode .isDisplayed (). Pouvons-nous obtenir du code html pour cet élément ou lien.
Je commence à croire la même chose ... cet élément Par superPoseLoading = By.xpath ("// span [@ class = 'loading']"); Il ne peut pas être validé avec un isDisplayed (), j'ai aussi essayé isEnabled () mais cela a créé des cycles infinis ...
Cette approche pourrait avoir des problèmes avec des exceptions levées lorsque l'élément n'existe pas par exemple. Je recommanderais d'utiliser une approche comme celle-ci: Je suis vraiment désolé d'utiliser thread.sleep () ici. Je viens de montrer une idée.
J'ai une approche légèrement différente de quelques-unes des autres réponses - si aucune d'elles ne fonctionne pour vous, n'hésitez pas à essayer ceci:
WebDriverWait wait = new WebDriverWait(driver, 30);
// first, wait for the loadmask to be visible to avoid race condition
wait.until(ExpectedConditions.visibilityOfElementLocated(By.xpath("//span[@class='loading']")));
// now, wait for load mask to disappear -- loading complete after this
wait.until(ExpectedConditions.invisibilityOfElementLocated(By.xpath("//span[@class='loading']")));
Ce code vérifie la présence du loadmask, et gère la NoSuchElementException qui peut survenir si elle n’existe pas. Nous définissons loadingFinished sur true si loader.isDisplayed () est false, ou si l'appel de findElement sur le chargeur renvoie une NoSuchElementException , ce qui signifie que l'élément n'existe pas et que le chargement est terminé.
Cependant, si vous voulez rendre ce code beaucoup plus simple, vous pouvez simplement utiliser le Classe ExpectedConditions :
By loadingIndicator = By.xpath("//span[@class='loading']");
boolean loadingFinished = false;
while (!loadingFinished)
{
System.out.println("is loading");
// attempt to find the loading indicator, catch exception if it is not found
try {
WebElement loader = driver.findElement(loadingIndicator);
// check isDisplayed(), set found to true
if (!loader.isDisplayed()) loadingFinished = true;
// handle exception where loadmask no longer exists
} catch (NoSuchElementException e) {
loadingFinished = true;
e.printStackTrace();
}
}
Votre deuxième bloc est ce que j'utiliserais (sauf que je n'utiliserais pas un sélecteur CSS, span.loading ). Une préoccupation que j'ai est que vous puissiez rencontrer une condition de course où le code recherche le chargement ... Popup pour être visible avant Il est effectivement présent, ce qui ferait le contournement de l'attente et ensuite le code ultérieur échoue parce que le chargement ... Popup ouvre et bloque d'autres clics. J'ajouterais une attente pour visible puis attendre que Invisible soit sûr d'être sûr.
Cela a du sens - j'ai mis à jour la réponse pour éviter la condition de concurrence. Le seul «inconvénient» de l'utilisation de ExpectedConditions est que vous ne pouvez pas imprimer «est en cours de chargement ...» en attendant. Mais je préfère l'approche ExpectedConditions de toute façon, cela dépend juste de ce que le demandeur initial essaie d'accomplir.
c'est très étrange, le problème n'est pas dans la méthode ou la validation qui est utilisée, que span [@ class = 'loading'] essaie d'utiliser un Thread.sleep (2000); comme test d'attendre que la fenêtre de chargement disparaisse puis de la valider avec un invisibilityOfElementLocated () et de lancer une erreur ... le problème vient de la page, également merci pour votre aide ^^
Je viens de prendre // span [@ class = 'loading'] de l'exemple de code que vous avez fourni. Comme je ne peux pas voir le code HTML sur votre page, je ne suis pas sûr de ce que devrait être le localisateur réel pour cela. Utiliser l'attente explicite ici n'est vraiment pas une bonne pratique, surtout parce que vous savez sur quel élément vous attendez.
@Christine Dans votre dernier commentaire lorsque vous déclarez, "Utiliser l'attente explicite ici n'est vraiment pas une bonne pratique ...", je suppose que vous faisiez référence au Thread.sleep () ? Vous avez peut-être mal compris que vous parliez de Conditions attendues .
À droite, ExpectedConditions est un type d'attente explicite, donc je me réfère spécifiquement à Thread.Sleep () .