We value your privacy
We use necessary cookies to make Loadero work. We ask for your permission to set additional cookies to understand site usage, make site improvements and to remember your settings. We also use cookies set by other sites to help deliver content from their services. See Cookie Policy for more info.
Skip to main content

Download files during the test

Some scenarios may require downloading a file for reasons such as simply generating load on the service that is responsible for streaming files or, e.g., so that you can upload the file to an e-signature service, to perform testing on it.

Since test participants use browsers as a means of interacting with the web application being tested, they have access to many of the features that come with that browser, including being able to download a file and store it in the browser's Downloads folder.

Triggering file downloads in a test​

File downloads are triggered in the same way a regular user would trigger them. If a user can cause a file download to start by clicking on a button, then the test participant will start a file download the same way. Since an ongoing download is not something that blocks further interactions with the UI, the test does not wait for active downloads to finish and will continue script execution even after initiating a download, unless instructed otherwise by the script. The "Wait for Download Finished" command provided by Loadero can be used in the script to instruct the test to wait for the download to complete before continuing.

caution

Using the "Wait for Download Finished" command to confirm that a file has been downloaded requires you to know what the file's name will be. If the file name is randomly generated at the time of prompting the download, then you will not be able to instruct the command on the exact file that needs to be waited for.

info

Downloads can be triggered via direct URL navigation, however, this will only work for participants using a Google Chrome browser. Participants using Mozilla Firefox must trigger the download by other means, such as a button on the page being tested, which triggers the download.

Downloading the same file repeatedly​

If downloading a file of the same name multiple times, it will be processed the same way as if you tried downloading the same file multiple times on your own local browser. As such, you should keep in mind two things:

  1. A suffix will be added to the file name for duplication handling, e.g., exampleFile (1).jpg instead of exampleFile.jpg. The format of the suffix depends on the browser type. Google Chrome will process duplicates as shown above, by inserting a space and an index in parentheses in between the file name and the file extension. For Mozilla Firefox participants, however, there is no space before the index, i.e., it will be exampleFile(1).jpg instead.
  2. Due to the introduction of parentheses into the name because of the index, the full file name will also be encased in apostrophes and will need to be referenced as such - 'exampleFile (1).jpg' or 'exampleFile(1).jpg', depending on the browser. This is because of how file paths are handled on the instances hosting the participants.

In summary, if you download a file named exampleFile.jpg twice, you will end up with two files in the Downloads folder - exampleFile.jpg and 'exampleFile (1).jpg' (Google Chrome) or 'exampleFile(1).jpg' (Mozilla Firefox).

A script example is provided below.

client => {
    client
        // Open the DemoQA upload/download page
        .url('https://demoqa.com/upload-download')
        .waitForElementVisible('#app', 1000)

        // Download the file
        .waitForElementVisible('#downloadButton', 10 * 1000)
        .click('#downloadButton')

        // Wait for the download to finish
        .waitForDownloadFinished('sampleFile.jpeg', 30 * 1000)

        // Download the same file again
        .click('#downloadButton')

        // Wait for the download to finish again
        // Google Chrome will save the file as "'{name} (1).{extension}'"
        .waitForDownloadFinished(`'sampleFile (1).jpeg'`, 30 * 1000)
        // Mozilla Firefox will save the file as "'{name}(1).{extension}'"
        // .waitForDownloadFinished(`'sampleFile(1).jpeg'`, 30 * 1000)
        .saveScreenshot("file_downloaded_twice.png");
}

Accessing downloaded files mid-test​

caution

This feature is currently only available when using the Nightwatch.js framework.

After the file has been downloaded, it can be found under /home/seluser/Downloads/. If you have downloaded a file during the test and wish to upload it elsewhere still within the same test, you should use the "Set File" command, making sure to prefix the file name with the previously mentioned path, e.g., /home/seluser/Downloads/downloaded_file.jpg. You can find an example of how to do so here.

Viewing downloaded files after the test has ended​

If you have executed a test where one or multiple files were downloaded and this test was executed in performance test mode, then any participant that executed these downloads will have the downloaded files in the "Artifacts" tab within their result report. This can be useful for confirming that the downloaded file's contents match expectations. Downloaded files are not served in the "Artifacts" tab directly, but in a compressed format (.gz archive). Each download is compressed individually, i.e., if you have downloaded two files, you will find two .gz archives in the "Artifacts" tab, one for each file.

If the combined size of downloaded files exceeds 100 MB, then these files will not be available in the result report. In summary, for a participant to have the downloaded files available in the result report, these conditions must be met:

  • The test must be executed in performance test mode;
  • The participant must have downloaded at least one file during the test;
  • The combined size of all files downloaded by the participant must not exceed 100 MB before compression.
info

You can download files in a test regardless of test mode, but the downloaded files will show up in the result report only for tests that were executed in performance test mode.