I am using Firefox and the Selenium IDE plugin. I have a test for the login of my application. After the end of the test the browser stays logged in and the session gets reused. Can this be avoided ?
You need to invoke driver.quit() method within the tearDown() {}. Invoking quit() DELETEs the current browsing session through sending "quit" command with {"flags":["eForceQuit"]} and finally sends the GET request on /shutdown EndPoint.
References
You can find a couple of relevant detailed discussions in:
Selenium : How to stop geckodriver process impacting PC memory, without calling driver.quit()?
PhantomJS web driver stays in memory
Related
I'm writing a series of tests with Robot Framework, that involve the supposed user closing the web browser (Chrome) during a session of the tested web-service and then re-opening the browser, automatically resuming the session.
My issue is, that with the Close Browser - Open Browser -combination in Robot Framework a fresh browser is always opened every time, and thus the user is logged out of the service and session is ended.
I tried getting and adding the cookies with the built-in Selenium keywords, but I was unable to resume the session that way. Doing the task manually works as intended.
Apparently it is not possible to attach Selenium to an existing browser session created launched for example by a custom Python keyword.
Is this something that is possible in Robot Framework and what kind of solution should I look for? Thank you.
I'm trying to understand the performance impacts of things like WebDriver.findBy(...). For example if I was using Selenium to drive a local Chrome instance:
WebElement betty = webDriver.findBy(By.id("betty"));
Does the Selenium library
a) have the DOM within the JVM to evaluate?
b) go to the local Chrome driver binary to evaluate?
c) go to the browser instance to evaluate?
And does the answer change for a Grid situation?
I found a nice technical guide that explains this.
The browser driver uses an HTTP SERVER which waits continuously for
new Selenium commands.
It has the following purposes:
read HTTP requests coming from the client (client = computer that executes the test automation scripts)
determines the series of steps needed for implementing the Selenium command
sends the implementation steps to the browser
gets the execution status from the browser
send the execution status back to the client
For each Selenium command of the automation script, a http request with a specific path is created.
When the automation script is executed, the first http request generates a new session that is specific to the browser where the automation scripts run.
The session id will be used for the http requests that correspond to all other
Selenium commands from the automation script.
When I run my selenium tests using a chrome browser all my tests cases run fine. When using the phantomjs browser it would appear that the browser session does not get reset after each test case. In my tests cases, I log in as a user to then navigate to certain pages and then logout. A problem occurs when a test case happens to fail. The browser session is not reset so when the next test case begins, the test that failed was unable to logout. This causes all test cases after a single failure to fail.
When searching the internet for a solution to this issue it been known sine 2013. I can't seem to find anything regarding this issue that's recent. Is there any up to date workarounds?
Manually trying to delete the cookies before or after each test case does not appear to work. webDriver.manage().deleteAllCookies();
I'm using phantomjs ver 2.1.1.
First of all PhantomJS is dead, you are better off switching to Headless Chrome or Headless Firefox.
Secondly PhantomJS is a port of Webkit which is not thread safe. This means that if you try and run more than one test in parallel you will see threading issues, to fix this you would need to start multiple instances of PhantomJS and have each GhostDriver instance connect to a different instance of PhantomJS.
The particular problem that you are seeing is that PhantomJS doesn't clear itself down properly, again the only solution would be to kill the initial PhantomJS instance you are running after your test finished and then start up a clean new one, unfortunately that is not supported by GhostDriver.
The final problem is that GhostDriver is dead as well, there was no point in continuing development when PhantomJS died.
TLDR; Use Chrome/Firefox Headless mode instead.
If a Geb test fails, it would be nice to inspect the page with a browser's developer tools. Is it possible to configure Geb in a way, that it stops on failure but keep the browser window open?
From http://www.gebish.org/manual/current/configuration.html:
7.2.3 Driver Caching
...
Also, by default Geb will register a shutdown hook to quit any cached
browsers when the JVM exits. You can disable this by setting te config
property quitCachedDriverOnShutdown to false.
I so tried set do that in GebConfig.groovy:
quitCachedDriverOnShutdown = false
And that keeps the browser open even after all tests are finished or one has failed.
I have a test where I need to do a login, close browser and open it again then check something on the page.
How can I do this when running webdriver with remote hub setup? or do i have to run this without remote?
Test is something like this:
Open browser
Login
Close browser
Open browser again
Check login is remembered
The process to accomplish this is going to be very similar to that of a solution in a non-grid environment. Note that the following code is written for Java, but I can't imagine C# being much different.
WebDriver driver = new RemoteWebDriver("hubURL", desiredCapabilities);
driver.manage().deleteAllCookies();
driver.get("http://path/to/page");
//login to application
driver.quit(); //This will close the browser on the remote machine
//Now to try it again
driver = new RemoteWebDriver("hubURL", desiredCapabilities);
driver.get("http://path/to/page");
Assert.assertTrue(some element that is not on the login page but is on the page after is present);
driver.quit();
Presumably you're testing some cookie stuff. Unfortunately, there's no guarantee any particular node will execute any request, unless you constrain it properly. You need to have a node advertise a unique capability that the client then requests, ensuring the hub will route to that node every time. But, naturally, if that node goes down, you won't have any others that could service the request.