Les fenêtres de Firefox ne se ferment pas après l'exécution du test Selenium
J'ai fait tourner mon sélénium à l'aide de tests selenium rc pour environ 6 mois, et tout à coup le firefox windows sélénium s'ouvre à ne pas fermer lorsque le test est terminé.
Je suis à l'aide d'un profil firefox et n'avait pas mis à jour mon selenium rc jar. J'ai pensé que peut-être la dernière version de firefox peut avoir été le problème, mais j'ai repris la version 2 de firefox et windows toujours rester ouverte.
Je suis l'exécution du test sur un Windows boîte.
J'ai remarqué que d'autres personnes semblent avoir ce problème - je me demandais si quelqu'un a une solution?
Grâce,
Gearoid.
source d'informationauteur Ger
Vous devez vous connecter pour publier un commentaire.
Ma solution a été d'utiliser
driver.quit()
(ce sera de l'auto de fermer le navigateur Firefox) au lieu dedriver.close()
- même si il n'y avait qu'une fenêtre de Firefox ouvert, autant que je sache.Solution très simple en fin de compte à juste appelé SeleniumTestCase de tearDown (), méthode (ie. nous appelons super.tearDown(); à partir de notre base de test de la classe)
Qui ferme toutes les fenêtres de navigateur avec succès.
Nous avons eu ce problème et après quelques recherches, nous l'avons fixé.
En Sélénium RC vous avez le fichier "grid_configuration.yml", où vous avez la liste des navigateurs et de leurs respectifs identificateur, par exemple "*firefox".
En fonction de votre environnement lorsque vous exécutez "firefox", vous serez probablement appel d'une cape, d'un alias ou d'un lien symbolique de firefox fichier exécutable.
Lorsque le Sélénium est lancé, il crée une certaine fourchette de processus pour le navigateur et en fonction de si vous appelez le firefox fichier exécutable directement ou un wrapper, la création de ces processus est différent et quand il essaie de tuer le processus dans le tearDown (), cela tue le processus de l'enfant et de garder le père vivant, de sorte que le tearDown() ne pas fermer le navigateur.
La solution est d'éditer le "grid_configuration.yml" fichier en changeant "*firefox" pour le chemin d'accès absolu du navigateur fichier exécutable (toujours avec * au début)
Nous utilisons Microsoft est disponible gratuitement sysinternals pskill outil pour tuer le navigateur (y compris firefox).
Par l'exécution de
pskill "firefox.exe"
qui va tuer une fenêtre de FireFox.Si vous avez besoin de l'exécuter sur un ordinateur distant, vous pouvez utiliser
[psexec][3]
. Aussi pour les deux il y a des commutateurs de commande automatiquement accepter le CLUF (-accepteula) de sorte que vous n'avez pas à.Gearóid: je ne vois pas comment cela pourrait résoudre le problème. super.tearDown() est appelée automatiquement après chaque test, de toute façon, afin de faire un appel supplémentaire ne ferait que rendre le lancer deux fois.
J'ai remarqué que les fenêtres du navigateur ne s'arrêtent pas jusqu'à ce que le Sélénium serveur est arrêté. Donc, dans mon cas, si il y a 100 sélénium tests, j'aurais 200 Firefox windows open avant qu'ils ne soient finalement fermé lorsque le Sélénium sort du serveur.
(Je suis sous Fedora 13 et Firefox 3.6.7)
À l'aide de TestNG, vous pouvez faire précéder le
teardown()
fonction avec un@AfterMethod
ou un@AfterTest
annotation, au lieu de@AfterClass
.Si vous utilisez python à la fin de votre démontage utilisation
super(unittest2.TestCase,self).tearDown()
À l'aide de MSTest, j'ai été l'appel de pilote.Quit() dans le TestCleanup mais j'ai garder jusqu'à la fin avec un chargement de Firefox windows open à la fin des épreuves.
J'ai trouvé que un NoSuchElementException semble empêcher le pilote de succès de l'appel à cesser afin enveloppé le TestCleanup avec un try/finally:
Cela a fonctionné avec le problème que j'ai continué à avoir, mais il peut être le cas que j'ai pour l'emballage de tous mes Méthodes avec try/finally. C'est loin d'être idéal, mais je ne semble plus avoir de fenêtres laissées ouvertes quand je fais cela.
J'ai eu le même problème. Je suis en cours d'exécution de Sélénium dans le cadre de mon Visual Studio tests unitaires et a été d'avoir le même problème avec Firefox, pas de fermeture à la fin des tests.
Deux choses corrigé cela pour moi:
1) j'ai mis à jour le /core dossier dans le site avec une version à jour.
2) j'ai trouvé que le sélénium a été l'appel de mon Set Up de la méthode dans une classe de base deux fois. De manière contre - intuitive (au moins pour moi), il semble que le sélénium appelle la mise en place de la méthode dans une classe parente automatiquement. Si vous essayez d'appeler dans un ensemble d'un enfant de la classe (c'est à dire avec quelque chose comme base.setup () ), il sera exécuté deux fois, et d'ouvrir Firefox windows, il ne peut pas fermer. J'ai enlevé les appels à la base.setup() et toutes mes fenêtre supplémentaire problèmes ont été résolus.
Simple jours à partir de la question du 3ème anniversaire, j'ai soumettre encore une autre obscure solution:
Mon Firefox a été dans un emplacement personnalisé. Parce que je ne voulais pas garder le bébé personnalisé argument JVM chaque fois que j'ai couru mon Sélénium tests en local, j'ai mis un relais de script dans
/usr/local/bin
. Sans doute le Sélénium était en train de tuer le processus, il a commencé (mon script), pas le navigateur.Donc je suis de retour à l'aide de l'argument JVM pour navigateur personnalisé emplacements:
-Dwebdriver.firefox.bin="/path/to/firefox"