-
Notifications
You must be signed in to change notification settings - Fork 1
Playwright snapshot testing
Snapshot testing allows us to assert on how a page or element should look after various user flows or actions. Some items are difficult to assert specific statements on. For example we could assert that an element is visible which will pass a test. However we may not know if the element actually looks the way we expect it to.
Hence with by using snapshots it gives an extra layer of confidence that the software is acting as it should. Snapshot testing has mainly been used on echart elements with mocked data. So the graph will always look the same and we can catch any functional regressions.
Method to wait for all network activity to cease, before taking a screenshot.
Example of snapshot method called in test.
Above is a simple test which is asserting that once all the user flows have been executed such as setting the base_date
the final UI should look like so:
Here some mock data has been added to make PM2.5 cause a plot of AQI 3 on the in-situ line.
There is also some added logic to ensure that the page has finished loading before taking the screenshot.
- The most reliable way to take a snapshot is to use the
toMatchSnapshot('')
Playwright method. inside the quotes will be whatever the image shall be named and it's format for exampletoMatchSnapshot('cool-cat.png')
- Note that this snapshot method requires that you run it through command line
npx playwright test
with filename or test name as optionals. Now upon running that command the test should fail like so:
Since the test cannot find an image to compare against, it will add the image that it got from running the test regardless.
- Now update and tweak any tests until the actual image provided satisfies requirements. This will be your golden image which is basically just your expected image. Once satisfied with that image use the
--update-snapshots
flag which will then set that image in your codebase as the comparison snapshot.
For example I have a test called "Epic Test" of which i am now satisfied with the comparison image. I can enter npx playwight test -g "Epic Test" --update-snapshots
which will now set that image as the golden standard for specifically that test.
- Since we currently have playwright working across 3 browsers (Chromium, Firefox, Webkit) then playwright will create 3 golden images each corresponding to a browser:
This is done as each browser acts differently. One common difference is how Webkit (Safari) will have a snapshot that is 2x the size of Chromium and Firefox dimension wise. This is due to how browsers and viewports may have different device pixel ratios
Updating snapshots requires some time to manually check that the new updated image is correct.
- Sit down with developers to confirm whether or not certain snapshots should be updated based on new implementation.
- This could also mean going through a code review to spot new functionality that could affect any snapshots.
- If there are new changes then you may need to update your test steps or locators to facilitate this.
- Once happy, run the test with
--update-snapshots
to create a new comparison image. The name will remain the same, but the snapshot will update.
Note that upon taking a snapshot it will be added to a new directory named after the related .spec.ts file.
Getting Started and Overview
- Product Description
- Roles and Responsibilities
- User Roles and Goals
- Architectural Design
- Iterations
- Decision Records
- Summary Page Explanation
- Deployment Guide
- Working Practices
- Q&A
Investigations and Notebooks
- CAMs Schema
- Exploratory Notebooks
- Forecast ETL Process
- In Situ air pollution data sources
- Notebook: OpenAQ data overview
- Notebook: Unit conversion
- Data Archive Considerations
Manual Test Charters
- Charter 1 (Comparing ECMWF forecast to database values)
- Charter 2 (Backend performance)
- Charter 3 (Forecast range implementation)
- Charter 4 (In situ bad data)
- Charter 5 (Filtering ppm units)
- Charter 7 (Forecast API input validation)
- Charter 8 (Forecast API database sizes)
- Charter 9 (Measurements summary API input validation)
- Charter 10 (Seeding bad data)
- Charter 11 ()Measurements API input validation
- Charter 12 (Validating echart plot accuracy)
- Charter 13 (Explore UI after data outage)
- Charter 14 (City page address)
- Charter 15 (BugFix diff 0 calculation)
- Charter 16 (City page chart data mocking)
- Charter 17 (Summary table logic)
- Charter 18 (AQI chart colour banding)
- Charter 19 (City page screen sizes)
- Charter 20 (Date picker)
- Charter 21 (Graph consistency)
- Charter 22 (High measurement values)
- Charter 23 (ppm -> µg m³)
- Charter 24 (Textures API input validation)
- Charter 25 (Graph line colours)
- Charter 26 (Fill in gaps in forecast)
- Charter 27 (Graph behaviour with mock data)
- Charter 28 (Summary table accuracy)
- Re‐execute: Charter 28
- Charter 29 (Fill in gaps in situ)
- Charter 30 (Forecast window)
- Charter 31 (UI screen sizes)