File uploads, downloads and the file system
You might want to use (binary) files in your browser checks. For example, you might want to upload a file to an upload form in your webapp. Or, you might want to validate some aspect of a file that is available for download on your app.
Testing downloads with the download
event and Download
object
Playwright has a download
event that you can use to intercept downloads. You can also use the Download
object to retrieve
the contents and metadata of the downloaded file(s).
In some cases, you immediately want to also test a related upload functionality using the downloaded file. In that case,
you can for instance spawn a new page, and use the .setInputFiles()
method to upload the downloaded file.
Check the official docs right here
Testing uploads with the browser’s File API
To test any upload features with Playwright’s .setInputFiles()
method, you need to provide a file object. Currently,
Checkly does not have a dedicated storage layer where you could upload that file, so you need to host it yourself at a (publicly)
accessible location like an AWS S3 bucket, Dropbox or any other file hosting service.
In the example below, we do not need to interact with the file system. We can just:
- Fetch a file from a public URL using the
request
object. - Pass the resulting
Buffer
into the.setInputFiles()
method. - Wait for the upload to finish.
Notice we don’t need to interact with the file system, we can just pass buffers around.
Testing uploads using HTTP POST requests
You can also “upload” files using a simple HTTP POST request with a (binary) body using Playwright’s built-in request
object.
You would use this when you want to test a file upload feature that is not using the browser’s File API, but just an HTTP/REST endpoint
that accepts a file upload.
Using the file system
Sometimes, you do want to explicitly save a file to disk. This is what you need to know.
Checkly creates a sandboxed directory for each check run. During the run you can use this directory to save or upload artifacts. This directory is destroyed after a check is finished.
Due to this sandbox, certain Node.js variables are adapted to our platform and have values we set for them. The behaviour is slightly different when creating a browser check in the Web UI or using the Checkly CLI.
When creating a browser check in the Web UI, the variables are:
__dirname
will have the value of/
__filename
will have the value of/script.js
When creating a browser check using the Checkly CLI the variables are:
__dirname
will have the value of/
__filename
will have the value of the actual file in your code base, relative to the project root.
Last updated on December 13, 2024. You can contribute to this documentation by editing this page on Github