Traditional browser testing approaches involve complex setups, manual interventions, and time-consuming maintenance. Maintaining compatibility across different browsers and operating systems can add overhead to the development process. Luckily, Playwright, an open-source Node.js library by Microsoft, provides an elegant solution to these challenges.
Paired with GitHub Actions, a powerful automation tool integrated into GitHub's platform, Playwright enables developers to automate browser testing effortlessly and efficiently. By defining custom workflows using YAML syntax, you can automate various tasks, including building and testing code, deploying applications, and running Playwright tests on multiple platforms.
In this post, we’ll explore how to get started with Playwright and GitHub Actions.
What Is Playwright?
Playwright is an open-source automation and web testing framework that’s cross-platform, cross-browser, and cross-language. Playwright's capabilities allow for thorough end-to-end testing of web applications. You can validate user interactions, test across different browsers and devices, and ensure the application works as expected in various scenarios.
Playwright integrates seamlessly with CI/CD pipelines and testing frameworks, making it suitable for automated testing in development workflows.
What Is GitHub Actions?
GitHub Actions is an automation tool by GitHub that allows developers to automate various tasks, workflows, and processes directly within their GitHub repositories. GitHub Actions provides a CI/CD (continuous integration/continuous deployment) service that helps streamline the development and release workflows.
With GitHub Actions, you can create custom workflows using YAML syntax by declaring a series of steps to be executed when certain events occur, such as a push to the repository, a new pull request, or an issue being created. You can use workflows to perform a wide range of tasks, like building and testing code, deploying applications to various environments, running automated tests, or publishing packages.
How Do I Run Playwright Tests on GitHub Actions?
Using Playwright with GitHub Actions allows you to automate browser testing as part of your continuous integration (CI) workflow. In this detailed explanation, I'll cover how to set up Playwright with GitHub Actions, handle possible corner cases, and provide examples of common scenarios.
Assumptions
You have a GitHub repository with a web application that needs browser testing.
You have basic knowledge of GitHub Actions, Git, and Playwright.
Find the perfect Proxy Product.
Residential proxies
Datacenter proxies
7 Day Trial
Setting up Playwright in a GitHub Repo
We’ll use Node.js and npm to install Playwright but you can use any of the languages supported by Playwright.
In your project run the following command:
npm init playwright@latestYou’ll be prompted to choose your language, name your test directory, install Playwright browsers, and add GitHub Actions workflows. Ensure that you agree to include GitHub Actions.
The scaffold will create sample tests, configuration files, and a GitHub Actions workflow.
Creating a Workflow That Uses Playwright
Open your project in your code editor and go to .github/workflows/ folder where you’ll find the sample playwright.yml file.
name: Playwright Tests
on:
push:
branches: [main, master]
pull_request:
branches: [main, master]
jobs:
test:
timeout - minutes: 60
runs - on: ubuntu - latest
steps:
- uses: actions / checkout@v3
- uses: actions / setup - node@v3
with:
node - version: 18
- name: Install dependencies
run: npm ci
- name: Install Playwright Browsers
run: npx playwright install--with-deps
- name: Run Playwright tests
run: npx playwright test
- uses: actions / upload - artifact@v3
if: always()
with:
name: playwright - report
path: playwright - report /
retention - days: 30The workflow above is triggered on every push and pull request to the main branch.
The job test runs on an Ubuntu environment (ubuntu-latest). You can use other environments like macOS or Windows. There’s a maximum runtime of 60 minutes for the entire job. That way the job gets canceled if it exceeds this time limit.
The steps include:
Checking out the repository code using actions/checkout@v3 onto the runner.
Setting up Node.js 18 using actions/setup-node@v3.
Installing dependencies with npm ci to ensure a clean install based on the package-lock.json.
Installing the browsers required by Playwright, along with their dependencies.
Running Playwright tests with npx playwright tests.
Uploading generated Playwright report as an artifact using actions/upload-artifact@v3 by specifying the path and an if condition. The if: always() condition specifies that the actions/upload-artifact step should always run, regardless of the test job's success or failure.
Ensure that you have the package.json and package-lock.json files containing your Playwright tests, along with the Playwright's dependencies and scripts defined.
GitHub Actions will automatically pick up and execute the workflow whenever the defined events are triggered. You'll be able to monitor the test execution directly from your GitHub repository's Actions tab.
You can adjust the workflow according to your specific Playwright test setup, including any custom configurations, environment variables, and artifacts you may want to include or save during the test run.
Optimizing Playwright Testing in GitHub Actions
Optimizing Playwright testing in GitHub Actions involves configuring the workflow and the Playwright setup to make the tests run efficiently and ensure a smooth testing experience.
Some useful tips include:
Caching Dependencies
Caching node_modules or other dependencies can significantly speed up workflow execution by avoiding redundant installations and restoring the cache from previous runs.
When a workflow runs, it needs to install all the dependencies listed in the package.json file. This can take a significant amount of time, especially if the dependencies are large or if the workflow runs frequently.
Caching allows you to store the dependencies that were installed during a previous workflow run in a local cache. When a workflow runs again, it can check the cache to see if the dependencies are already there. If they are, the workflow can skip the installation step and simply restore the dependencies from the cache.
For example, if a workflow takes 10 minutes to run without caching, it could take only 1 minute to run with caching.
Use the actions/cache action to cache and restore dependencies. Here's an example:
- name: Cache Node.js modules
uses: actions / cache@v3
with:
path: ~/.npm
key: ${ { runner.os } } -node - ${ { hashFiles('**/package-lock.json') } }
restore - keys: ${ { runner.os } } -node -
Adjust Upload Artifact Condition
Artifacts are files generated during the workflow that you want to persist for later access or download. Saving test reports, screenshots, and videos as artifacts allows developers to access and review the results after the workflow completes. To customize your workflow, you can adjust the if statement from always() to failure() such that you upload artifacts with reports only when test cases fail. That way, you manage the size of your artifact storage and avoid unnecessary artifact uploads when tests pass successfully.
- uses: actions / upload - artifact@v3
if: failure()
with:
name: playwright - report
path: playwright - report /
retention - days: 30
Parallel Testing
Parallel testing involves splitting your test suite into multiple smaller jobs that run simultaneously on separate runners to reduce overall testing time. Running tests in parallel significantly speeds up test execution, providing faster feedback on code changes and reducing the time developers spend waiting for test results. Use GitHub Actions' built-in matrix strategy to create parallel jobs with different configurations. The matrix strategy allows you to run the same job with multiple configurations, such as different browsers, versions, or environments. For example, the configuration below runs our tests in parallel across different operating systems.
jobs:
test:
strategy:
matrix:
os: [ubuntu - latest, macos - latest, windows - latest]
runs - on: ${ { matrix.os } }
Publish Reports to GitHub Pages
Publishing test reports to GitHub Pages is a useful practice because it allows you to create a dedicated web page to display test results, making it easy for team members to access and review test outcomes without navigating through the GitHub Actions logs or artifacts. GitHub Pages provides a user-friendly interface for presenting test reports in a visually appealing and easily shareable format.
However, you'll need to enable GitHub pages and select the source to GitHub Actions from the repository settings. You'll then set up GitHub actions to deploy the report in your YAML file using configure-pages and upload-pages-artifact actions.
- name: Setup Pages
uses: actions / configure - pages@v3
- name: Upload artifact
uses: actions / upload - pages - artifact@v2
with:
# Upload failure report
path: "playwright-report/"
- name: Deploy to GitHub Pages
id: deployment
uses: actions / deploy - pages@v2
Conclusion
Playwright and GitHub Actions offer a game-changing solution for automating browser testing and enhancing your web application development workflow. Playwright's powerful browser automation capabilities, coupled with GitHub Actions' flexible CI/CD automation enables you to effortlessly perform end-to-end testing, validate cross-browser compatibility, and catch potential issues early in the development process. Integrating Playwright and GitHub Actions streamlines the testing and deployment pipeline, providing faster feedback loops and rapid iterations.
This post was written by Mercy Kibet. Mercy is a full-stack developer with a knack for learning and writing about new and intriguing tech stacks.
