Sunday, June 23, 2013

Best use of webDriver.Quit() Close() Dispose() or it will eat your hard drive

Recently I found that some of VM's I share with coworkers were running out of hard drive space, I was surprised to find that the reason was webDriver.Quit() wasn't being called. My cohorts were running code or NUnit tests in the debugger and forcing the code execution to stop. Stopping execution this way was ensuring that [TearDown] and [TestFixtureTearDown] weren't being called, which is where we had placed the Quit() call. To put this in perspective one of my cohorts had over 18 Gb of data in his appData folder because of this.

What to do when done with the WebDriver
It's important to make sure to free up the driver at the end of the run by calling the Quit() method. Calling the Quit method will clean up temporary files created and in the case of RemoteDriver it will also close the session on the Selenium Server.

I Did some Googleing and didn't really find an answer that I thought I could trust, so I turned to the source code and found the following:

webDriver.Close() - Close the browser window that the driver has focus of
webDriver.Quit() - Calls dispose
webDriver.Dispose() Closes all browser windows and safely ends the session

In summary ensure that Quit() or Dispose() is called before exiting the program, and don't use the Close() method unless you're sure of what you're doing. I found this unanswered question on StackOverflow

What happens if you don't Call WebDriver.Quit() before exiting the program
The result will be that files are abandoned in your appData folder. And in the case of the remote driver the Selenium Server will not have ended the session properly, causing a memory leak in the Selenium Server.

I wouldn't have guessed this to be a problem for several reasons, first I would have thought those files would be cleaned up when doing a disk clean up. That assumption was incorrect even though these files are being written to a temp folder its one that Disk cleanup doesn't work on. Second as I rarely hit the "Stop" button in the debugger and therefore my appData folders aren't blowing up like the housing market. The reason I don't like to stop execution like that is when you let execution continue it ensures we get a NUnit log and all teardowns take place, in our case that means un-managed objects are cleaned up screenshots and logs are written. Having these logs and screenshots make it easier to troubleshoot and do investigation.