Utilizarea implicitWait cu getElements încetinește serios timpii mei de testare (Programare, Java, Scala, Selenium, Selenium Webdriver, Scalatest)

laura a intrebat.
a intrebat.

Lucrăm în cod moștenit și avem o problemă cu testele slabe.

Aș dori să măresc timpul de așteptare implicit, dar driver.findElement este utilizat într-o mulțime de locuri – suprascrierea fiecărui apel pentru a utiliza WebDriverWait ar fi o sarcină mare.

Am găsit o recomandare de a folosi așteptări implicite, care părea ideală, deoarece trebuia setată doar o singură dată:

getDriver().manage().timeouts().implicitlyWait(5000, TimeUnit.MILLISECONDS);

Am adăugat acest lucru la blocul de cod de inițializare. Din nefericire, atunci când execut un caz de testare (50 de teste), performanța mea explodează – crescând de la ~30 de secunde la 600 de secunde.

Nu înțeleg de ce performanța s-a înrăutățit atât de mult – am crezut că ar fi durat maximul de timp doar dacă elementele nu ar fi fost prezente (testele au trecut). Am crezut că acest apel va căuta condiția. Dar nici nu văd unde să setez intervalul de interogare… În documentație se menționează că ar trebui să fie folosit în mod judicios, dar acest lucru este complet inutilizabil!

Suntem pe drumul cel bun cu utilizarea implicitlyWait()? Există o altă modalitate de a ne întări testele?

UPDATEOn investigație, se pare că utilizarea implicitlyWait() și driver.getElements() este cea care ne încetinește – dacă anulez implicitwait și apoi îl reaplic imediat după apel, testele rulează mult mai repede. Folosim getElements în peste 400 de locuri (!) – aveți vreo recomandare despre cum să procedăm?

Comentarii

  • Suspectez cu tărie că situația este mai complicată decât ar sugera o singură linie de cod pe care ați postat-o aici. În teorie, aveți dreptate, deoarece termenul implicit de așteptare ar trebui să aștepte doar perioada completă de așteptare dacă elementul nu este găsit. Ar putea fi util să vedeți codul real al cazului de testare care a început să aibă performanțe slabe. De asemenea, ar fi util să știm dacă acest lucru se întâmplă în toate browserele sau doar într-unul, iar dacă doar într-unul (sau dacă rulezi doar împotriva unuia), care este browserul și versiunea. –  > Por JimEvans.
  • Vă mulțumim pentru răspuns. Am început să avem aceleași suspiciuni. Din păcate, din cauza naturii dispersate a codului moștenit, este dificil să arătăm mostre de cod reprezentative utile… acum vânăm sursa problemei. Este bine de știut că suntem totuși pe drumul cel bun – mulțumesc! –  > Por laura.
  • Întrebare actualizată cu mai multe informații –  > Por laura.
1 răspunsuri
laura

Nu am reușit să depistăm de ce se întâmpla acest lucru cu implicitlyWait. În interesul de a face construcția noastră fiabilă, am scris overrode getElement cu propriul nostru mecanism de interogare, cu un interval de interogare destul de mic (100ms).

Acest lucru a îmbunătățit acuratețea testelor noastre, fără a afecta durata compilării.

override def findElement(selector: By): WebElement = {
      val timeoutTime = System.currentTimeMillis() + timeout
      def helper(): WebElement = {
        try {
          super.findElement(selector)
        } catch {
          case exception: NoSuchElementException => {
            if (System.currentTimeMillis() >= timeoutTime) {
              throw exception
            } else {
              Thread.sleep(pollInterval)
              helper()
            }
          }
        }
      }
      helper()
    }