I am using Watir-Webdriver with Firefox and the method recommended on the watirwebdriver.com site to automate file downloads. This involves setting FireFox about:config parameters to disable the download dialog in FireFox for specific file types. This works well but now I am trying to figure out how best to determine when the file download has completed (some take a few seconds, some take minutes) so I can logout of the site and move on to the next test. It seems since there are no visual clues left in the browser I may have to monitor the file in the download directory. Any options would be appreciated.
标签:
watir-webdriver
相关问题
- how to exactly match using :class selector in wati
- Best practice to keep common steps of cucumber
- watir-webdriver black screenshots
- Can not use variable in IRB after var = Watir::Bro
- Selenium or Watir Webdriver, how to save resized s
相关文章
- selenium grid with cucumber
- `marshal data too short` error message while insta
- Watir-Webdriver Wait for Download to Complete
- Save image with watir-webdriver
- Save screenshot with Watir
- How to find the data-id in watir?
- Make headless browser stop loading page
- Setting a text field that has a JQuery mask on it
Chrome stores uncompleted downloads with an added
.crdownload
file extension. Check to see if the download directory has a file ending with.crdownload
and that should tell you if a download is still ongoingThe way i handle this, is the following
Firefox download files end with .part
have all files' names being downloaded in a list after appending ".part" to them keep on looping on that list and check if any of those files still exist in the lsdir of the download folder
Python code:
note: when there are no part files in
os.listdir('.')
, that means downloading is finishedI had a similar task where I wanted to extract the contents of a downloaded PDF file. I used to following solution:
It does 20 attempts at extracting the text using the shell command pdftotext and will break out of the block if the shell command was successful. The advantage of doing it this way is that if the file doesn't exist or if the file is only partially downloaded it will produce an error and then try again. If your file is not a PDF or you don't care about the contents then you use another shell command instead of pdftotext, so long as it produces an error if the file is incomplete.
Maybe you can track the file size to see when it stops changing for a few seconds.
I have a bit different approach for file-downloads automation. I do it like this:
The requiures:
First create a method for the Filesize handling:
Secondly drive chrome with pre set-up download dir:
Next delete the file (from previous runs) for test case re-usability and validness (one of 3):
Define the size variable of the downloaded component:
And lastly you can include the validation point:
I didn't like just looking at filesize, it felt fragile, so I ended up using the lsof command to detect when there are no processes holding the file open, and then reading the file. It's better in that a pause in the download due to network hiccups won't cause intermittent errors, but worse(?) in that it is not portable and shells out to the lsof command.
The coded looked something like this: