Le finestre di Firefox non si chiudono dopo l'esecuzione del test del selenio

Question

Ho eseguito i test del selenio utilizzando il selenio rc per circa 6 mesi e all'improvviso l'apertura del selenio di Firefox non si chiude quando il test è terminato.

Sto utilizzando uno specifico profilo firefox e non ho aggiornato il mio barattolo di selenio. Ho pensato che forse l'ultima build di Firefox potrebbe essere stato il problema, ma sono tornato a Firefox 2 e le finestre rimangono aperte.

Sto eseguendo il test su una casella Windows.

Ho notato che altre persone sembrano avere questo problema - mi chiedo solo se qualcuno ha una soluzione?

Grazie, Gearoid.

Answer 1

soluzione molto semplice, alla fine - appena chiamato il metodo di SeleniumTestCase tearDown() (vale a dire che noi chiamiamo super.tearDown(); dalla nostra classe di test di base.)

che chiude tutte le finestre del browser con successo.

Answer 2

Utilizziamo lo strumento sysinternalspskill di Microsoft liberamente disponibile per terminare il processo del browser (incluso il firefox).

Eseguendo pskill "firefox.exe" che uccide una finestra di FireFox.

Se è necessario eseguirlo su un dispositivo remoto, è possibile utilizzare [psexec][3]. Anche per entrambi ci sono commutatori per accettare automaticamente l'EULA (-accepteula) in modo da non doverlo fare.

Answer 3

Gearóid: Non riesco a vedere come questo risolverebbe il problema. super.tearDown() viene chiamato automaticamente dopo ogni caso di test in qualsiasi modo, quindi effettuare una chiamata aggiuntiva lo farebbe girare solo due volte.

Ho notato che le finestre del browser non si arrestano finché il server Selenium non viene arrestato. Quindi, nel mio caso, se ci sono 100 test sul selenio, avrò 200 finestre Firefox aperte prima che vengano chiuse alla chiusura del server Selenium.

(io sono in esecuzione Fedora 13 e Firefox 3.6.7)

Answer 4

Utilizzando TestNG, si può precedere la funzione teardown() con una @AfterMethod, o un @AfterTest annotazione, invece di @AfterClass.

Answer 5

Abbiamo avuto questo problema e dopo alcune indagini l'abbiamo risolto.

Nel Selenium RC si ha il file "grid_configuration.yml" in cui si ha l'elenco dei browser e il loro identificatore, ad esempio "* firefox". A seconda dell'ambiente in cui esegui "firefox" probabilmente chiamerai un wrapper, un alias o un link simbolico del file eseguibile di firefox. All'avvio del Selenium, viene creato un processo a forcella per il browser e, a seconda che si chiami il file eseguibile di firefox direttamente o un wrapper, la creazione di questo processo sia diversa e quando tenta di terminare il processo in tearDown() in realtà uccide il processo figlio e tiene in vita il padre, così il tearDown() non chiude il browser.

La soluzione è modificare "grid_configuration.yml" il file che cambia '* Firefox' per il percorso assoluto del file eseguibile del browser (sempre con * all'inizio)

Answer 6

Se si utilizza python alla fine per l'utilizzo da tearDown super(unittest2.TestCase,self).tearDown()

Answer 7

mia soluzione era quella utilizzare driver.quit() (questo chiuderà automaticamente il browser Firefox) anziché driver.close() - anche se c'era una sola finestra di Firefox aperta, AFAIK.

Answer 8

Utilizzando MSTest, stavo chiamando driver.Quit() nel TestCleanup ma continuo a finire con un carico di finestre di Firefox aperte alla fine dei test

Ho scoperto che NoSuchElementException sembra impedire al conducente di chiamare con successo smettere così avvolto il TestCleanup con un try/finally:

[TestCleanup] 
     public void TestCleanUp() 
     { 
      try 
      { 
       driver.FindElement(By.Id("ctl00_btnClearSession")).Click(); 
       WebDriverWait wait = new WebDriverWait(driver, TimeSpan.FromSeconds(10)); 
       wait.Until((d) => { return d.FindElement(By.Id("ctl00_btnClearSession")).Displayed; }); 
      } 
      finally { 
       driver.Quit(); 
      } 
     } 

Questo ha funzionato con il problema che ho mantenuto dover ma può essere il caso che io devo avvolgere tutti i miei TestMethods con try/finally. Questo è tutt'altro che ideale, ma non mi sembra più che le finestre siano state lasciate aperte quando lo faccio.

Answer 9

Ho avuto lo stesso problema. Sto eseguendo Selenium come parte dei miei test di unità di Visual Studio e stavo avendo lo stesso problema con i browser Firefox che non si chiudevano alla fine dei test.

due cose fisse questo per me:

1) Ho aggiornato la cartella/core sotto il sito web con una versione aggiornata.

2) Ho trovato che il selenio chiamava il mio metodo di impostazione in una classe base due volte. Contrariamente intuitivamente (almeno per me) sembra che il selenio chiami automaticamente il metodo di impostazione in una classe genitore. Se provi a chiamarlo in una configurazione di una classe figlia (cioè con qualcosa come base.setup()) verrà eseguito due volte e aprirà le finestre di Firefox che non può chiudere. Ho rimosso le chiamate su base.setup() e tutti i miei problemi con le finestre extra sono stati risolti.

Answer 10

giorni Mere dal 3 compleanno della domanda che sostengono un'altra soluzione oscura:

mio Firefox è stato in una posizione personalizzata. Poiché non volevo fare da babysitter a un argomento JVM personalizzato ogni volta che eseguivo i test del selenio in locale, inserivo uno script passthrough in /usr/local/bin. Presumibilmente il selenio stava uccidendo il processo iniziato (il mio script), non il browser.

Quindi sono tornati a utilizzare l'argomento JVM per le posizioni del browser personalizzato:

-Dwebdriver.firefox.bin="/path/to/firefox"