E2E tests verify Ionic components in a real browser. This is useful for testing user interaction and catching visual regressions. We use Playwright as it allows us to test in multiple browsers. Tests can be written and run using Playwright’s public API.
Follow these steps to install Playwright dependencies. These steps must also be run whenever the installed version of Playwright changes to ensure that you are testing with the correct browser binaries.
core directory: npm cinpx playwright installIonic uses Docker to provide a way to run tests locally in the same environment that is used on CI. Using Docker is optional as all tests can be run locally on your host machine, but there are a few reasons why you might want to use Docker to run tests locally:
The Running Tests and Managing Screenshots sections show how to perform various tasks in Playwright with Docker. The section below shows how to configure your environment to get set up with Docker.
Docker can be installed by following the steps on the Docker website.
Additional software is needed to run headed tests inside of Docker. The Docker-specific test commands such as npm run test.e2e.docker are configured to use this additional software, but it is up to the developer to ensure that the software is installed and running.
Playwright relies on XServer, a windowing system used to draw and move windows on a display, in order to run tests in headed mode. Follow the steps below to install XServer on your computer.
[!NOTE] The following instructions are based off https://www.oddbird.net/2022/11/30/headed-playwright-in-docker/
macOS uses XQuartz to use XServer on macOS.
brew --version to check if Homebrew is installed.brew install --cask xquartzPreferences > Security, and check “Allow connections from network clients”.xhost +localhost/tmp/.X11-unix in Preferences > Resources > File sharing.core directory run echo host.docker.internal:0 > docker-display.txt. This information is used to set the DISPLAY environment variable which tells Playwright how to render a headed UI from the Docker container.core directory run echo /tmp/.X11-unix:/tmp/.X11-unix > docker-display-volume.txt. This information is used to make XServer available inside of the Docker container.Windows has a native XServer called WSLg that is included as part of the Windows Subsystem for Linux (WSL). If you are running Docker Desktop on Windows 10 or 11 you likely already have both WSL and WSLg installed. The following steps show how to verify the WSL and WSLg are installed as well as how to configure your environment for headed tests in Docker.
If either of the below verification checks fail, then developers should download the latest version of WSL.
ls -a -w 1 /mnt/wslg. If the command fails with No such file or directory then your system is either missing WSL or running an old version.core directory run echo :0 > docker-display.txt. This information is used to set the DISPLAY environment variable which tells Playwright how to render a headed UI from the Docker container.core directory run echo /tmp/.X11-unix:/tmp/.X11-unix > docker-display-volume.txt. This information is used to make XServer available inside of the Docker container.All E2E tests can be run using the following command:
npm run test.e2e
[!NOTE] This command is a wrapper for
npx playwright test. All data passed tonpm run test.e2ecan also be passed tonpx playwright test.
Specific test files can be run by passing the file paths or a directory that contains multiple test files. See Managing Screenshots for generating ground truths before running screenshot tests.
Specific Test Files
npm run test.e2e src/components/button/test/basic/button.e2e.ts src/components/button/test/a11y/button.e2e.ts
Test Directory with Multiple Files
# Will run all the test files in the `test` directory
npm run test.e2e src/components/button/test
While npm run test.e2e can be used to run tests in the same environment that you are developing in, npm run test.e2e.docker can be used to run tests in a Docker environment provided by the Ionic team. This command supports all the same features as npm run test.e2e detailed in the previous section.
This command builds a Docker image before tests run. It will also re-build the Docker image in the event that a Playwright update was merged into the repo.
Note that the Playwright report will not automatically open in your web browser when tests are complete because the tests were run in Docker. Run npm run test.report outside of Docker to open the most recent test report.
[!NOTE] Additional setup is needed to run Playwright tests with headed mode in Docker. See Configuring Docker for Headed Tests for more information.
Playwright tests in Ionic are run in headless mode by default. This means that a visual representation of the browser does not appear on your computer while running.
No additional steps are needed in order to run the tests in headless mode:
# Will run tests in headless mode
npm run test.e2e src/components/chip
Playwright supports the --headed flag to run in headed mode which causes the visual representation of the browser to appear:
# Will run tests in headed mode
npm run test.e2e src/components/chip -- --headed
If you are running a test that takes a screenshot, you must first generate the reference screenshot from your reference branch. This is known as generating a “ground truth screenshot”. All other screenshots will be compared to this ground truth.
We recommend generating ground truths inside of Docker. This allows anyone contributing to Ionic Framework to create or update ground truths.
To create or update ground truths, run the following command:
npm run test.e2e.docker.update-snapshots
Optionally, you can pass a directory to only update the ground truths for that directory & subdirectories. This is useful when working on a specific component.
npm run test.e2e.docker.update-snapshots src/components/alert/
The resulting screenshots should be committed and pushed to your branch.
While we recommend generating ground truths inside of Docker it is possible to generate ground truths without it. Note that these generated ground truths can only be used for local testing and will not update the ground truths stored in the repo.
If the reference branch has changed since the last time you generated ground truths you may need to update your local ground truths.
For most types of work the reference branch is typically main. Features are merged into a different branch, so developers should use that as the reference branch. For example, if branch foo will be merged into bar, then the reference branch is bar.
The examples provided in the Running Tests section also apply here, allowing you to update screenshots for a specific test file.
Note that since you are generating the reference branch ground truth screenshots, you must be on the reference branch locally. Don’t forget to pull the latest reference branch changes and then re-build using npm run build.
npm run test.e2e.update-snapshots
Optionally, you can pass a directory to only update the ground truths for that directory & subdirectories. This is useful when working on a specific component.
npm run test.e2e.update-snapshots src/components/alert/
From here, you can switch back to your branch and run the tests.
[!NOTE] Locally generated ground truths should not be committed to the repo. The
.gitignorefile prevents this from accidentally happening.
[!IMPORTANT] Only Ionic Team members can update ground truths on the main repo. Ground truths cannot be updated on forked versions of the repo. Instead, we recommend generating ground truths in Docker.
When making an intentional visual change, you will need to update the ground truth screenshots or add new ones. It is important that the ground truth and comparison screenshots are taken in the same environment, so do not update the ground truth screenshots locally and commit them to the repo.
Instead, use the Update Reference Screenshots GitHub Action.
This workflow will re-run the screenshot tests. Instead of failing any tests with mismatched screenshots, it will take new ground truth screenshots. These ground truth screenshots will be pushed as a single commit to your branch once the workflow is completed.
When any of the screenshot tests fail, it means a potential regression was caught. Developers must manually verify the difference in the Playwright test report.
If the screenshots fail on CI then developers must download the build artifact. On the Summary page for a particular workflow, find the Artifacts section. Screenshot tests are currently parallelized across several test runners, and the results from each of those runners is included in an artifact with the following naming scheme:
test-results-[current shard]-[total shards]
Example:
test-results-2-5 --> Test results from job runner 2 out of 5.
Download the appropriate artifact and unzip the file.
In the newly created directory, open the playwright-report/index.html in your browser. From here, you will be able to see the tests that failed as well as the expected screenshot, the actual screenshot, and the pixel differences.
[!WARNING] It is recommended to verify the screenshot difference within the Playwright test report first. If you choose to try and reproduce the difference in a browser manually, make sure you are using the exact same browser version that Playwright is using.
For more info on how to use Playwright, please see the Playwright documentation.