Attendez que l'élément de WebDriver - PageObject modèle

Vous devez attendre que vos éléments dans votre page objet de la classe, pas dans la classe de test, parce que vos éléments doivent être définis dans la page objet de la classe, de la classe de test doit rien savoir de tout les éléments, de sélecteurs, ou similaire. Tests, à mon humble avis, ne devrait contenir que des chaînes d'appels de méthode que de décrire le test de débit, toutes les interactions avec le site web sous-jacents et les DOM devrait prendre place dans la Page de la classe d'Objet.

Donc trop verbeux méthode à attendre pendant un certain élément d'apparaître pourrait être quelque chose comme:

private final By yourElement = By.id("id");
@Override
public void isLoaded() throws Error {
    new FluentWait<WebDriver>(driver)
            .withTimeout(60, TimeUnit.SECONDS)
            .pollingEvery(1, TimeUnit.SECONDS)
            .ignoring(NoSuchElementException.class)
            .ignoring(StaleElementReferenceException.class)
            .until(new Function<WebDriver, Boolean>() {
                @NotNull
                @Override
                public Boolean apply(WebDriver webDriver) {
                    WebElement element = driver.findElement(yourElement);
                    return element != null && element.isDisplayed();
                }
            });
}

En clair, la fonction si l'interrogation du DOM pour 60 secondes (1 seconde) pour voir si l'élément existe dans les DOM et il est visible (moyens a la hauteur et la largeur de plus de 1px). Si l'élément existe (et est affiché), la fonction retourne l'élément trouvé et arrête le scrutin (bien que isLoaded() la méthode ne retourne pas l'élément dans ce cas particulier).

Il est logique de les ignorer NoSuchElementException qui peut être levée par findElement méthode dans le cas où l'élément n'est pas trouvé, et StaleElementException, ce qui indique qu'une référence à un élément, c'est maintenant "vicié" - l'élément n'apparaît plus sur le DOM de la page. Cela signifie que quelque chose (le plus souvent JS) a modifié les DOM et la référence n'est plus valide, d'où le WebDriver besoin de regarder de nouveau.

De parcours plus court code également pour l'astuce, quelque chose comme:

    new WebDriverWait(driver, 60)
            .until(ExpectedConditions.visibilityOf(someWebElement));

La la documentation est en fait assez bon sur ce.

EDIT: réponse au commentaire de:

OK, compris. Mais que faire si l'élément est présent après en cliquant sur certains
bouton etc.?

Disons que vous avez un scénario où vous avez un bouton et après avoir cliqué sur ce bouton, une boîte de dialogue s'affiche et vous souhaitez interagir avec elle.

public class PageObject extends LoadableComponent<PageObject>{

    public PageObject() throws Exception {
        driver = getWebDriver();
        PageFactory.initElements(driver, this);
        isLoaded();
    }
    private WebDriver driver = null;

    @FindBy(id = "yourButton")
    private WebElement button;

    @FindBy(id = "textBoxThatAppears")
    private WebElement txtBox;

    @Override
    public void isLoaded() throws Error {
        //Initial loading, called when creating the page object to make sure that the page is loaded to a state where it is ready to interact with us, in our case it means that button is present in DOM and visible.
        waitForVisibility(button);
    }

    private void waitForVisibility(WebElement element) throws Error{
           new WebDriverWait(driver, 60)
                .until(ExpectedConditions.visibilityOf(element));
    }

    public void clickButton(){
        button.click();

    }

    public void interactWithTextbox(String text){
        //Wait for txtBox to be visible, then send text
        waitForVisibility(txtBox);
        txtBox.sendKeys(text);

       //EDIT 27.04.14: 
       //Actually you should not do the assertion here or anywhere in 
       //the pageObject, because when reusing the method in some other test, you might
       //not want to assert, you might wonder that why wouldn't you assert some 
       //specific condition every time, but I would throw that question right back 
       //to you and ask: What is the point of checking the exact same thing over and 
       //over again. There are 2 things, firstly the assertion takes resources (and
       //that can become important when test suite grows, secondly your tests can 
       //simply start failing at the same point when one little condition is not as
       //it should be. Also, having the asserts in the test, makes the test more
       //readable and understandable for others.
         //end edit 27.04.14
        //Next line is no longer recommended by this answer.
         //assert that something happened that you expected.
    }

}

Et maintenant votre classe de test:

public void TestClass {

     @Test
     public void testClickButtonAndInteractWithTextbox(){
         //Initiate the page object
         Pageobject po = new PageObject();
         po.clickButtonAndWaitForTextbox();
         po.interactWithTextbox("blabla");
         //edit 27.04.14
         assertSomethingGoodHappened();
     }
}

OriginalL'auteur Erki M.