2017-02-08 9 views
1

私は、次のような方法作成しました:要素が古くなるのを待っていますが、なぜ 'ExpectedConditions.stalenessOf'は機能しませんか?

public void waitAndClickElement(WebElement element) throws InterruptedException { 
    try { 
     Boolean elementPresent = this.wait.until(ExpectedConditions.elementToBeClickable(element)).isEnabled(); 
     if (elementPresent == true && element.isDisplayed()) { 
      element.click(); 
      System.out.println("Clicked on the element: " + element.getText()); 
     } 
    } catch (StaleElementReferenceException elementUpdated) { 
     Boolean elementPresent = wait.until(ExpectedConditions.stalenessOf(element)); 
     if (elementPresent == true) { 
      WebElement staleElement = element; 
      staleElement.click(); 
      System.out.println("Clicked on the 'Stale' element: " + element.getText()); 
     } 
    } catch (NoSuchElementException e) { 
     System.out.println("Exception! - Could not click on the element: " + element.getText() + ", Exception: "+ e.toString()); 
     throw (e); 
    } finally { 
    } 
} 

を私はまだ下に次の例外を取得するように見える:

予想される条件に失敗しました:DefaultElementLocator「By.xpath::のための要素を待っている(プロキシ要素//[テキスト()=のExchange今»は、 『]』) enter image description here

)500ミリ秒間隔で(20秒(秒試してみました)陳腐化するのではなく、同じ方法での20のうち18を言わせて上で動作しますビルド、任意のアイデア?あなたが別のdriver.get("http://completely.different.site.com/");でサイトを変更する場合は、

+0

の代わりにあなたのロジックのすべての?これは 'WebElement'をどのように作成するかによって異なりますが、キャッシュされたルックアップを使用している場合は常に古くなりますが、' FindBy'のように使用されているメソッドを使用している場合それは、それが古くないまでクリックしようとし続けます。 – mrfreester

答えて

1

あなたの質問に対する直接的な答えは、あなたがすでに古くなった要素が古くなるのを待っていることです。私はあなたの意図がそこにあったのか分かりません。

あなたの機能は非常に複雑で、思うように機能しません。

要素がクリック可能であるならば、それはまた、有効と表示されたので、あなたはすべての3つをチェックする必要はありませんです。要素がStaleElementReferenceExceptionを投げている場合、それは "unstale"になることはありません。

現在の機能を以下のように置き換えることをお勧めします。

public void waitAndClickElement(By locator) 
{ 
    try 
    { 
     this.wait.until(ExpectedConditions.elementToBeClickable(locator)).click(); 
    } 
    catch (TimeoutException e) 
    { 
     System.out.println("Count not click element <" + locator.toString() + ">"); 
    } 
} 

要素自体の代わりに要素の代わりにロケータを渡すと、多くのことが簡単になります。要素が存在し、クリック可能な場合は、その要素がクリックされます。存在しないか、クリック可能にならない場合は、キャッチできるTimeoutExceptionがスローされます。

また、element.toString()を書くこと読めるか意味のある人間であることを行っていない要素のためのいくつかのIDを書き込むことが起こっています。 locator.toString()と書くと、ロケータのタイプを返す方がよいでしょう。 By.cssSelector: #hplogo。もう一度 `` waitAndClickElement(要素)を呼び出していない理由を、あなたの `キャッチ(StaleElementReferenceException)`ブロック、中

+0

おかげでそんなに再び上記のコメントを参照してくださいするときに私のコードは唯一のテストケースの小さなmanorityに失敗しているようだ理由を知っている必要があり – Gbru

+0

私はあなたが一度必要と思うほど多くの時間を待つでしょう。二度待っても何も成立しません。たとえば、30秒間待機する場合は、15秒間待機する場合と同じです。それはもっと理にかなっており、より明確であり、30秒間に一度待つコードが少なくなっています。 – JeffC

+0

あなたの助けをもう一度ありがとう、try&catchブロックの代わりに 'Exception e'を使用する方が良いでしょうか? – Gbru

1

を助けるため

おかげで、この要素は(これ以上のDOMで)古くなります。 Stalenessは、DOMの要素にアクセスできないことを意味します。

+0

ありがとう、しかし、私のテストの実行の大部分は、同じテストで奇妙な時間を過ごすだけです。このエラーは、例えば3つのビルドが20のうち失敗した場合に表示されます。 – Gbru

+0

失効した要素は決して存在しません。だからここに何か間違っている: 'Boolean elementPresent = wait.until(ExpectedConditions.stalenessOf(element));'、あなたがやりたいことに応じて。 –

+0

これはちょっと変わったのですが、たとえリストされたメソッドであっても要素はまだ古くなっているようです。 – Gbru

関連する問題